Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Posts Tagged ‘sistema’

Sistemas operativos en la web

Posted by josempelaez en Domingo, 21 septiembre 2008

Los ingenieros de Google han querido brindar una herramienta de navegación para la web de hoy y de mañana. Las aplicaciones que cada vez ocupan más tiempo de navegación necesitan apoyarse en un "navegador" más rápido, robusto y seguro. ¿Estaremos asistiendo al nacimiento de un nuevo "sistema operativo" de la web?

google_engineers

Algunos de los ingenieros de Google que hablan en el vídeo

«¿Por qué Google está construyendo un navegador?» es la traducción literal del título de un vídeo de Google sobre las ideas y características que hay detrás del navegador Google Chrome en palabras de varios miembros de su equipo de desarrollo. Me puso sobre su pista una entrada de Jose Miguel Cansado que terminaba diciendo: «it is pushing developers to bet on JavaScript rather than on Silverlight or AIR proprietary technologies for the web interactive applications.»

Los seis segmentos que componen los 4′ 50″ del vídeo tienen estos encabezados: Why is Google building a browser? Speed (V8 and Webkit). Stability. Security. The invisible browser. The code is yours. Del primero y dos últimos he sacado unas cuantas frases que he transcrito como he podido. Aunque haya algún error, el discurso de los ingenieros que lo han construido es claro:

«Browsers syndicate bad because they were designed for an earlier work; web pages are doing completely different things». «Today, most of what we use on a day to day basis are applications, and not web pages». «People are watching videos, they’re uploading videos, they’re chatting with each other, they’re playing games on the web… all these things certainly never existed back when the first browsers were created, when the first web was created». «We have been great to start from scratch and design from it… based on the needs of today’s applications and today’s webmasters». […]

«In an engineering browser sense, chrome is the… user interface itself; it’s the stuff running outside of the window, the buttons, the toolbars, all that kind of stuff; and so, hand in hand with that was this design philosophy that we took which was…, we wanted to maximize content and minimize chrome». «In designing any chrome we thought, we have to make it invisible; people shouldn’t have to think about Google’s chrome, people should have to think about their applications». […]

«We really want… the work that we do is sort of raise the bar for browsers, we want to push browsers further, we wanna make their capabilities better, we wanna be able to allow for better web applications to be delivered». «Even if Google Chrome itself isn’t used by anyone on the web…, as long as it makes the web better, we’ve achieved that goal».

google_chrome_engineer

Lars Bak, líder técnico del equipo de desarrollo de V8

Uno de los ingenieros comentaba que JavaScript es un lenguaje muy usado en todas las partes de la web. Como se ejecutaba lentamente, decidieron mejorar radicalmente este punto. Me he entretenido también con otro vídeo del líder técnico del equipo que ha desarrollado el nuevo motor (V8) para este lenguaje.

Lars Bak justifica su elección por ser multiplataforma al haberse utilizado casi desde el comienzo de la web para “personalizar” el comportamiento de los navegadores. También explica que han hecho tres cosas para incrementar su rendimiento: clases ocultas, código máquina generado y gestión eficiente de memoria.

Creo que estamos asistiendo a un rejuvenecimiento de los estándares canónicos de la web. En lugar de incrementar la diversidad creciente de plataformas, vemos que hay quienes tratan de ampliar el rendimiento y alcance de las herramientas existentes para adaptarse a los nuevos escenarios. Además, facilitan un código interesante a los desarrolladores que construyen aplicaciones diseñadas para una web más dinámica, visual y personalizable. Cumpliendo con el estándar, se podrá utilizar en plataformas diferentes sin tener que recurrir a herramientas de pago o a descargas auxiliares. El movimiento hacia la web de la plataforma de TV Joost podría ser otra confirmación de que no se necesita instalar una aplicación de escritorio para una buena experiencia de uso.

Me ha resultado llamativo que Sergio Montoro, más amigo del código abierto que de los enfoques académicos, se haya molestado porque piense que muchos nos confundimos con las categorías de producto. Digo molestado porque es lo que he deducido del contenido y estilo de lo que ha escrito:

«Me resulta sorprendente hasta que punto el buzz está confundiendo las categorías de productos. Chrome es un navegador, sólo eso: un puñetero y jodido navegador. Nacido de un comando rebelde de Mozilla que abogaba por Webkit en lugar de Gecko y se fue a Google a poner en práctica sus ideas. Chrome no es un paso en la dirección de fabricar un sistema operativo. Fabricar un sistema operativo es un algo extremadamente más complicado que fabricar un navegador. […]

Una máquina virtual que corre encima de un sistema operativo, no es un sistema operativo. Y aquí se confunden los terminos, hablando de JavaScript como “el lenguaje del futuro” y cosas así. ¿JavaScript? Pooor faavor… Un poquito de seriedad.»

splashtop_screenshot

Pantalla de «sistema operativo instantáneo» basada en Firefox 2 (Splashtop)

He leído bastantes cosas sobre Chrome. En muchos casos lo he visto relacionado con los sistemas operativos (SO), como en este artículo de Roger Smith, o en este otro del citado Jose Miguel Cansado. En ninguno lo he visto como un paso hacia un “verdadero” SO de Google. No implica que no esté escrito en algún lado, sino que yo debo de leer otros tipos de análisis. Donde he visto analogías con los SO, se hacían en el marco del uso de la plataforma web, que no deja de ser una clase de computadorathe network is the computer», «cloud computing»).

Entiendo que algunos se molesten en establecer clasificaciones y en categorizar las cosas, y que se reboten si otros no las usan como esperan. No entiendo ni comparto que Chrome se considere en este momento un navegador “como los demás”, aunque confío en que lo sea dentro de poco porque haya quienes sigan su camino, como esperan sus ingenieros.

Supongo que otra cosa que también habrá molestado a Sergio es que se sigan bifurcando los esfuerzos de los desarrolladores de código abierto, lo que tan poco ha favorecido la adopción de Linux, por ejemplo. ¿Debería de haber seguido Google a Mozilla en el empleo del viejo Gecko y del nuevo TraceMonkey como motor gráfico e intérprete de lenguaje? ¿Tendrán que ser los programadores de la Fundación los que adopten la tecnología de la entidad que tiene más medios para consolidarla en el mercado frente a la competencia no estándar o no abierta?

Estamos ante una nueva máquina virtual —el propio navegador, que tiene una gestión independiente de procesos, memoria, intérprete…— que corre sobre otra máquina virtual, que otra cosa no es el SO de turno que se ejecuta sobre la máquina o cacharro “real”. Me voy a saltar en esta ocasión el referirme a los “hipervisores” y SO “instantáneos“.

Pensando en Windows y MAC OS X, dadas las relaciones entre los fabricantes de software y hardware que los suministran preinstalado, no quedaría demasiado mal decir que estos SO son casi tan “firmware” como el software de las BIOS. En un entorno moderno no me parece descabellado considerar que el verdadero sistema con el que opera el usuario es el navegador, que ahora es más que una interfaz al poder servir y gestionar los recursos de las máquinas que tiene por debajo (terminal) y por arriba (nube).

Entradas relacionadas: Clientelismo para navegar, Interfaces en aplicaciones webNavegar por las aplicacionesJuegos de vendedores.

Posted in computación, web | Etiquetado: , , , , , , , | 3 Comments »

Paradojas en el proceso

Posted by josempelaez en Viernes, 4 julio 2008

Tras lo escrito en las tres anotaciones previas, creo que ya hay bastante consenso en que las estructuras maestras de datos no “han de ser” comunes en las aplicaciones empresariales —ni en otros tipos—. Obviamente pueden serlo, pero probablemente sea mejor que no lo sean. ¿Por qué?: porque así hay más…

  • flexibilidad, para reaccionar mejor ante los cambios,
  • rapidez de despliegue, al combinar y reusar componentes,
  • adaptación a distintos problemas, al configurar y reemplazar elementos,
  • control de riesgos, al poder evolucionar paulatinamente y emplear métodos ágiles de desarrollo,
  • economías, al aplicar estándares y no requerirse proyectos de integración complejos, etcétera.

CBDOtra de las grandes paradojas de los sistemas de información (SI) empresariales es que las consultoras de negocio y sistemas, que promovían su empleo con el discurso de la reorganización por procesos, luego solían prescribir sistemas más orientados a datos y documentos.

Lo primordial en los procesos son las relaciones, comportamientos y estados de los objetos que interaccionan como abstracciones de la realidad. Me refiero a planos, especificaciones, órdenes, acciones, tareas, movimientos, pedidos, viajes, cargas (mercancías), inventarios, entregas, facturas, apuntes… Cada uno de estos elementos sigue unas secuencias de pasos dependiendo de ciertos eventos (workflow), pasa por una serie de situaciones (states), y tiene una vida determinada con principio y fin (lifecycle).

Los típicos documentos de un sistema administrativo (partes, albaranes, listas…) se pueden considerar subproductos de información generados durante la ejecución de los procesos —según las fórmulas de la ingeniería y las reglas de los negocios— a partir de un suceso desencadenante (orden, petición, incidencia…). Teniendo el registro histórico de las transacciones detalladas se pueden extraer luego toda clase de informes estadísticos, paneles de indicadores operacionales, cuadros de mando directivos, análisis de rentabilidad por actividades, información agregada para decisiones…

Aquí encuentro otra paradoja porque, si un SI está orientado a los procesos, el tratamiento requerido de los documentos asociados (registros de información) se produce como una consecuencia lógica, pero ésto no suele suceder en sentido opuesto. Creo que hay un mal enfoque de muchos SI que se deriva de la simple mecanización de los viejos procedimientos administrativos. ¿Cuántas veces los programadores de los System/38, AS/400 y System i de IBM, tan usados en las medianas empresas industriales y comerciales, han tenido que borrar transacciones de movimiento de fondos o de mercancías porque alguien no quería que se viera lo que había sucedido realmente durante el proceso? ¿Es útil esta información adulterada?

Network SynchroEn los procesos, los datos maestros que se repiten en muchos documentos son secundarios. Incluso los que aplican el principio de unicidad de maestros no pueden impedir que existan datos duplicados. ¿No son también entidades proveedoras las clasificadas como clientes, aunque lo sean de otras organizaciones del «ciclo productivo»? ¿No debiera tener el componente “cliente” un comportamiento distinto según las circunstancias? El que sus atributos más estables puedan estar almacenados de manera consistente en varios sitios es un problema técnico que hoy ya está bien resuelto. Que se hable de replicación de bases de datos, coordinación de agendas, alineamiento de maestros, red global de sincronización de datos (GSDN )…, debiera de ser una cuestión menor.

En el diseño moderno de SI, ¿vamos a seguir empleando como restricciones las de la informática antigua?: ahorrar espacio de almacenamiento, normalizar datos para evitar redundancias e inconsistencias, programar sin parámetros ni reglas contingentes para procesar rápido, trabajar en local para eliminar indisponibilidades o latencias de red… ¡Qué paradoja que un sector de innovación tan acelerada siga lastrado por dificultades técnicas superadas!

En el campo empresarial de las operaciones —el que conozco mejor—, desde la extracción de la materia prima hasta su recuperación al final de su ciclo de vida útil, hay muchas actividades concatenadas que afectan a numerosas empresas de diversos tamaños y especialidad. ¿Cómo ha de tratarse la información asociada a esos procesos para gestionarlos mejor?

La visión de la empresa que se apoya en estructuras organizativas y maestras de información es anticuada. Replica organigramas y formularios propios de una organización tradicional ya superada. ¿De qué empresa hemos de tomar la “visión dominante” en una «demand-driven supply network»? ¿Por qué no pueden gestionarse directamente los procesos (comerciales, ingeniería, operativos, de personal, de sistemas, contables…) en lugar de los documentos, ya sean de una empresa o de una red de organizaciones? Cada abstracción de la realidad tiene sus datos de referencia y reglas asociados. Éstos no tienen por qué ser visibles desde el exterior del componente si se emplean esquemas de «petición-respuesta» en el funcionamiento de los SI. ¿Por qué han de estar agrupados en maestros comunes?

Service Oriented ArchitectureMe parece que las grandes consultoras industriales, que hace tiempo que aparcaron el discurso del BPR, ahora hablan mucho de SOA, BPM, ESB… Tengo dudas acerca de que sepan realmente, o de que quieran explicar bien, lo que ello implica, que es más que integrar servicios de aplicación. Me temo que sólo traten de seguir vendiendo jornadas de servicios profesionales a espuertas bajo una nueva etiqueta, como sucedía en los grandes proyectos de implantación de ERPs de hace pocos años.

A mí, la «arquitectura orientada a servicios» me refresca lo que aprendí en la universidad sobre resistencia de materiales, como recordaba en Maestros y estructuras. Las flexibles no se oponen de forma rígida a las acciones derivadas de los cambios del entorno que actuan sobre su periferia; se acomodan para no colapsar bajo su presión y poder conducir el esfuerzo resistente hacia unas bases sólidas de sustentación, servicio prestado por los cimientos. ¿Qué relación veo entre el análisis estructural y la arquitectura de servicios?

Para mí, un enfoque de SOA para los SI transaccionales debiera permitir trabajar con todos los variados y variables detalles que intervienen en las diferentes partes de los procesos. Es lo que considera un arquitecto o ingeniero cuando contempla las posibles acciones de viento, nieve, agua, vibración… que pueden impactar en las distintas partes de la estructura para calcular sus efectos. El análisis también debería contemplar servicios para guiar las acciones de cada agente participante (persona, equipo, máquina), registrar lo ocurrido en cada lugar e instante relevantes, y transmitir todos esos datos precisos, puntuales y plenos para su consolidación, como cuando se instrumenta una estructura resistente. Así se lograría una base de información real, no organizada necesariamente en documentos, sino más orientada a procesos, acciones o servicios. Ello permitiría decidir y dirigir mejor las empresas en todos los escalones de sus actividades sin tener que esperar obligadamente al final de cada semana o mes para que se hayan “cocinado” los datos relevantes.

Parafraseando a Eduardo Torroja, un tipo estructural de «sistema monolítico» basado estructuras maestras de datos comunes no va a adaptarse bien a los cambios; uno flexible armado con componentes que interactuan, encapsulando sus datos y reglas de comportamiento, sí que puede hacerlo. Se adapta sobre la marcha y no hay que post-procesar nada.

[Ilustración 1: Component-Based Development Cycle © OIG Ltd 2002-2003]
[Ilustración 2: XC Bridge, © Xchange Network]
[Ilustración 3: Service Oriented Architecture © eSchool News]

Posted in integración | Etiquetado: , , , , , | 3 Comments »