Los repositorios técnicos
Los problemas de integración
El director de los sistemas de información vela por la construcción de un edificio formado por aplicaciones. El conjunto de los procesos de la empresa se sostiene, en gran parte, por la informática.
La lógica a corto y a largo plazo se enfrentan continuamente. La primera busca una puesta en marcha a medida, bastante reactiva. La segunda desarrolla progresivamente un repositorio de aplicaciones capaces de interactuar. Se trata de obtener la famosa interoperabilidad.
1. Los desarrollos específicos
Los desarrollos específicos no siempre se encargan a proveedores externos. Es bien sabido que cada servicio tiene al menos una persona interesada en la informática, a la que solicitamos un poco de ayuda. El fruto de estas colaboraciones toma cuerpo rápidamente en forma de herramienta, al principio no oficial, pero rápidamente imprescindible durante el desarrollo de los procesos. La historia es análoga a la introducción de una pequeña aplicación de nicho open source en Internet, que se configura en pocos minutos y está operativa muy rápidamente.
Este tipo de desarrollo no es probable que funcione, a menos que subsista hasta la construcción de una segunda versión. Aquí las cosas se complican mucho, ya que lo rápido y barato se puede convertir finalmente en bastante caro si queremos mantener la misma eficiencia, a falta de una organización previsora.
Los desarrollos específicos bajo demanda tropiezan en la misma piedra; los esfuerzos de especificación se concentran normalmente en el corazón del problema, pero la lógica "industrial" destinada a estandarizar las partes técnicas, permanece en un segundo plano.
Conducir un proyecto de integración alrededor...
Las arquitecturas distribuidas
1. La separación en capas
La arquitectura lógica de las aplicaciones ha evolucionado considerablemente desde la aparición de Internet. Gartner Group ha popularizado "la separación en capas" y el enfoque n-tiers. El software, con el impulso de las nuevas tecnologías y de proyectos ambiciosos, se ha transformado para responder principalmente a las exigencias de evolución e integración.

Las "antiguas" aplicaciones (de las que intentamos deshacernos) eran difíciles de usar en contextos multiusuarios. La adopción masiva de la red las ha vuelto obsoletas y las ha convertido en difíciles de mantener debido a la ausencia de separación entre las diferentes capas de las que están compuestas. Esta ausencia de separación se debe principalmente a las tecnologías de desarrollo, pero también (y esto sí está relacionado) a la ausencia de restricciones vinculadas con el entorno de explotación.
La introducción de las bases de datos, incluso si algunas veces eran funcionalmente limitadas, ha cambiado la situación y ha restringido las arquitecturas que modifican la organización del software. De esta manera, las aplicaciones se hacen accesibles a varios usuarios al mismo tiempo.
Las aplicaciones "en red", por no decir "Web", han impulsado la lógica de separación en capas; la presentación se debe aligerar lo máximo posible, hasta el punto de que un simple navegador HTML/HTTP, inicialmente desprovisto de funciones...
Las arquitecturas orientadas a servicios (SOA)
Las arquitecturas orientadas a servicios (SOA) son el fruto de un encuentro entre la informática de los grandes sistemas y la de los servidores de aplicaciones (en "micros"). El gran sistema ha inyectado literalmente su filosofía "rápido y asíncrono" en el corazón de una arquitectura distribuida con poca evolución. Las arquitecturas basadas en componentes normalmente presentan dos problemas. Por un lado, el rendimiento de un proceso síncrono está limitado por los mecanismos de control de transacción y por el hardware, capaz de ejecutar los servidores de aplicaciones que los implementan. Por otro lado, el acoplamiento fuerte entre los componentes dificulta las capacidades de reconfiguración del sistema.
1. Los middlewares orientados a mensajes (MOM)
Los grandes sistemas utilizan dispositivos de tratamiento intermediario (middleware), basados en mensajes (MOM - Message Oriented Middleware). Se trata de colas de espera a las que enviamos una gran cantidad de mensajes. Un mensaje es una unidad elemental de información; se puede tratar de una orden, un dato, un evento de transacción...
Se ha abierto camino la idea de introducir estos middlewares dentro de los servidores de aplicaciones a base de componentes distribuidos. Los componentes ya no están controlados por los proxies, sino por mensajes.

Estos middlewares se han ido adaptando progresivamente a los servidores de aplicaciones Java y .NET, a través de API, ahora populares. Las colas de espera se definen como servicios y el tratamiento de los mensajes se delega a los componentes distribuidos, que operan de manera asíncrona. Respecto a una arquitectura síncrona clásica, el rendimiento es mejor, sin que por ello empeore la fiabilidad. Por el contrario, la ejecución asíncrona impacta...
Las plataformas tipo
1. Los generalistas J2EE y .NET
a. Java y J2EE
Java es un entorno creado en 1995 por Sun Microsystems, que ha dedicado prácticamente 15 años de I&D a la salida de este ambicioso programa.
En primer lugar, Java es un ordenador virtual (también llamado máquina virtual), es decir, un entorno de ejecución. Esta característica es particularmente estructurante, ya que su aplicación implica la creación de un lenguaje de programación, un lenguaje de ejecución (a nivel ensamblador), un API lo suficientemente desarrollada como para poder sustituir a un sistema operativo y una herramienta de ejecución.
Lenguaje de programación |
Lenguaje Java |
Lenguaje binario |
p-code |
Formato de los ejecutables |
.class y .jar |
API estándar |
API Java J2SE |
Máquina virtual (herramienta de ejecución de los programas) |
JRE (Java Runtime Environment) |
Los programas Java están escritos en archivos de extensión .java. Las instrucciones del lenguaje se desarrollan en reglas sintácticas parecidas a C++, pero respetando una cierta ortodoxia; todo aquello que estaba implícito en C++ prácticamente ha desaparecido del lenguaje Java. Había varios métodos que permitían desarrollar en C++ y solo se ha conservado uno de ellos en Java. El lenguaje Java también se basa en los paradigmas de objetos y en la programación basada en componentes, y estas influencias se notan mucho. Así, la herencia múltiple se ha transformado en una herencia simple y en la implementación de interfaces, que son suficientes para la programación distribuida y la implementación de servidores de aplicaciones.
El lenguaje Java también propone un mecanismo de métodos virtuales y enlaces en tiempo de ejecución (late-binding). Estas características también tienen un impacto en la arquitectura del entorno y en el proceso de compilación.
No se incorpora la edición de los enlaces, fase habitual de los lenguajes muy tipados, y se sustituye por una edición tardía de los enlaces que tiene lugar durante la ejecución (runtime):

El ascenso de Java es indisociable de sus entornos de desarrollo; en primer lugar, los programadores han estado limitados por la simplicidad de editores de texto con poca capacidad de construir soluciones de envergadura...
De los ASP al cloud computing
1. El acceso local a las aplicaciones
Ha aparecido un nuevo modelo para responder a los problemas de control de entornos, explotación de soluciones y limitación de inversiones relacionadas con la puesta en marcha de una solución: el acceso local a las aplicaciones, ASP o Application Service Providing.
De manera muy rápida, este modelo se ha enriquecido de un ecosistema de servicios que acompañan el acceso a la aplicación propiamente dicha, como las copias de seguridad, autentificación combinada (SSO o Single Sign On), estadísticas de uso, etc., y se ha pasado de esta manera del ASP al SaaS (Software as a Service).

El Saas se apoya normalmente en las aplicaciones de tipo cliente ligero -Web por ejemplo- aunque esto no es ni un principio ni una restricción. Por ejemplo, Microsoft ofrece sus aplicaciones en versión clásica Windows o en cliente web; la primera se comercializa (al menos durante un determinado tiempo aún) por licencia o por alquiler de acceso.
2. El cliente móvil: del portátil a la tableta
El segundo eje de esta reducción del sistema informático tiene que ver con el cliente que no necesita un ordenador personal ni un portátil para hacer funcionar aplicaciones ricas y potentes; los fabricantes han visto el importante interés por renovar el parque de software y hardware y proponer servicios Saas.
La tableta...