Arquitectura de N-Capas y N-Niveles
Arquitectura de N-Capas y N-Niveles
Lo que se conoce como arquitectura en capas es en realidad un estilo de programación donde el objetivo principal es separar los diferentes aspectos del desarrollo, tales como las cuestiones de presentación, lógica de negocio, mecanismos de almacenamiento, etc.
Los que aprendieron a programar con Pascal, recuerdan que con ese lenguaje todo estaba en la misma porción de código.
A lo mejor un progrador cuidadose organizaba las cosas en «units», pero al final todo esta amontonado.
Vamos a dejar de lado los servicios que el Sistema Operativo facilita para el manejo de archivos, esto es imprescindible
Muchos de nosotros debemos recordar que desde la aparición de los motores de base de datos existen dos «niveles» perfectamente definidos. Quiero resaltar el uso del término «nivel» y no el de «capa» porque no significan lo mismo. El término capa se utiliza para referenciar a las distintas «partes» en que una aplicación se dividide desde un punto de vista lógico; mientras que «nivel» corresponde a la forma física en que se organiza una aplicación.
Cuando programaba en COBOL las cosas también se hacian como en Pascal, pero había instalaciones donde se podía utilizar una Base de Datos y codificar la aplicación con COBOL; de este modo ya teníamos una separación en niveles:
Se puede observar con total claridad el nivel de aplicación (seguramente en ella existe código de presentación y lógica de negocio) y el nivel de datos (donde está la o las bases de datos de la organización). El objetivo de este esquema fue y sigue siendo el de lograr un único repositorio de datos para la organización y múltiples aplicaciones que utilizan esos datos
Ahora consideremos el ejemplo de un componente que permita grabar los programas de televisión emitidos. Este componente tiene un sistema de almacenamiento, dado que hace falta «guardar» las instrucciones sobre el día y hora se desea grabar el programa en particular; obviamente existe una porción de lógica de negocio, la que se refiere a los pasos necesarios para capturar el programa de televisión y grabarlo; finalmente hay una interfáz de usuario que permite a las personas ver y editar las instrucciones de grabación.
Podemos decir desde un punto de vista lógico que existen tres capas, y hasta que no veamos el código que escribió el desarrollador vamos a creer que es así.
Lo que no se puede negar es que hay un único nivel, todo esta empotrado en algún componente de hardware dentro del equipo.
Es importante destacar que hace falta separar el código de presentación del código de lógica de negocio, porque el fabricante puede desarrollar este equipo para que muestre las instrucciones en un display del mismo equipo o utilizar el televisor; la cuestión es que el código de presentación tiene que poder intercambiarse, lo cuál es una de las ventajas del desarrollo en capas
La necesidad de contar con porciones de la aplicación que se puedan «intercambiar» sin tener que modificar el resto de la aplicación es lo que impulsa el desarrollo en capas; de este modo nos encontramos con el siguiente diagrama
Ahora tenemos 2 niveles y en el primero de ellos diferenciamos 2 capas, de esta manera estamos diciendo que la capa de presentación interactua con la capa de lógica de negocion; Desde la filosofía de arquitectura en capas, esto significa que la capa de lógica de negocios presenta una «interfaz» para brindar servicios a la capa de presentación.
Del mismo modo, en el diagrama estamos diciendo que existe otro nivel donde se encuentra una capa encargada de los datos. Esta capa no se muestra como un «paquete» o «ensamblado» dado que se trata (generalmente) de un motor de base de datos que puede o no ejecutarse en el mismo equipo. Indudablemente esta capa también presenta una «interfaz» para brindar sus servicios a la capa que está por encima.
Lo importante y que siempre debemos recordar es que las capas inferiores brindan servicios a las capas superiores (independientemente del nivel en que se encuentren).
La clave del desarrollo en capas es que una capa solamente debe utilizar lo que la «interfaz» de la o las capas inferiores le brindan, de este modo se puden intercambiar las capas respetando la «interfaz», que viene a ser como un «contrato entre capas”
Ahora escribiendo nuevo código podemos intercambiar la capa de presentación sin afectar el resto de la aplicación. El problema se presenta cuando queremos intercambiar la Capa / Nivel de Datos, esto significa que necesitamos utilizar otro motor de base de datos y resulta que los fabricantes de motores de bases de datos si bién respetan los estándares, incorporan características valiosas en sus productos. Una aplicación que pretenda utilizar la «potencia» o características particulares de un motor de base de datos, inevitablemetne incorporará en la Capa de Lógica de Negocios algo de código que no es compatible con otros motores de base de datos. En consecuencia, cambiar la capa de datos significa corregir la capa de lógica de negocios.
Las buenas prácticas de diseño y desarrollo indican que se debe trabajar sobre el siguiente diagrama
Ahora si tenemos las tan famosas 3 capas, pero hay que hacer un par de aclaraciones para que nadie se confunda.
La nueva capa, se denomina Capa de Acceso a Datos (o Capa de Persistencia) que no es lo mismo que Capa de Datos.
La capa de acceso a datos es una porción de código que justamente realiza el acceso a los datos. De esta manera cuando es necesario cambiar el motor de base de datos, solamente tendremos que corregir esa capa.
Mientras que la capa de datos (en el nivel de datos) es donde están los datos y se corresponde directamente con la definición de esquemas, tablas, vistas, procedimientos almacenadaos y todo lo que se pueda o deba poner en un motor de base de datos
Los arquitectos están felices con este diagrama, sin embargo los desarrolladores tienen un problema. Resulta que los componentes de la capa de lógica de negocios necesitan referenciar a instancias de las «clases del dominio» (las que representan las entidades del negocio) y los componentes de la capa de acceso a datos también tienen que referenciarlas para poder «rellenar» tales instancias con los datos que obtienen de las capas inferiores.
La porción de diagrama de la Figura 6 (a) muestra algo que no se debe hacer, porque los componentes no pueden caer en un ciclo de referencias recursivo, no podría compilarse la aplicación ¿cuál de los dos ensamblados debe resolverse antes para poder compilar el otro?
Una posible solución se presenta en la Figura 6 (b), donde se muestra que la declaración de las «Entidades» se realiza en la capa de acceso a datos.
Bién esto también tiene un problema, la capa de acceso a datos surge porque no queremos «tocar» la lógica de negocio cuando cambiamos el nivel de datos, y con este esquema estamos incluyendo en la capa de acceso a datos uno de los aspectos más importantes, que es nuestra definición del dominio de la aplicación; los cambios en la capa de acceso a datos pueden impactar en las entidades.
Para pequeñas aplicaciones esto puede funcionar, incluso se puede poner ambas capas en un único ensamblado con diferentes nombres de espacio (namespace) pero a la larga traerá problemas.
La solución que satisface a los arquitectos y a los desarrolladores, es la siguiente:
Ahora tenemos otra capa más, la capa de Entidades que corresponde al dominio de la aplicación.
En esta capa se encuentra la declaración de las entidades de la aplicación, de manera que se pueden referenciar desde otras capas sin entrar en ciclos recursivos de compilación.
Además este esquema permite una total independencia entre la lógica de negocios (Business Model) y las entidades (Domain Model). Por supuesto que ambas partes están relacionadas por los casos de uso y otros requerimientos de la aplicación.
Por otro lado, este esquema facilita la incorporación, en la capa de acceso a datos, de componentes tipo ORM – Objet / Relational Mapping que permiten «mapear» (representar) objetos en un esquema relacional. Esto funciona bién dado que las bases de datos más utilizadas (por su mejor performance) son las bases de datos relacionales y no las orientadas a objetos (al menos por ahora).
El nivel de cooperación que presentan las organizaciones requiere que las aplicaciones de software de las distintas organizaciones interactuen unas con otras. El problema es que algunas de ellas no se ejecutan en la misma plataforma o están desarrolladas con marcos de trabajo diferentes. La solución fue presentada como SOA – Service Oriented Architecture, que brinda entre otras cosas una forma estandard de publicar y utilizar servicios, conocidos comunmente como servicios web (web services).
La Figura 8 muestra como los usuarios finales, mediante la utilización de hardware o software liviano, pueden acceder a lo que se denomina el nivel de clientes o aplicaciones que básicamente se constituyen de la capa de presentación y consumen los servicios publicados por la misma organización. Este tipo de aplicaciones son en general sitios o portales en la web.
Pueden implementarse soluciones del tipo cliente – servidor en donde el usuario final accede de manera directa a una aplicación de escritorio que consume los servicios publicados al igual que las aplicaciones para hardware y/o software liviano.
Aplicaciones de otras organizaciones también pueden utilizar los servicios publicados por una organización en particular, obviamente esto necesita de acuerdos comerciales y credenciales para autenticar y autorizar a quienes consumen los servicios
COMPUTACION EN LA NUBE
COMPUTACION EN LA NUBE
INTRODUCCION
Hoy en día no hay quien lo dude, la Internet con su creciente importancia se ha transformado en una de las principales palancas del mundo moderno, convirtiéndose en poco tiempo en la red comunicacional más trascendental en toda la historia si la comparamos con los medios tradicionales ya conocidos por todos. Se ha convertido en el dinamismo del planeta entero al compás de las (re)evoluciones tecnológicas, estimándose mas de 100 millones las personas que en el mundo ya se han hecho parte de este gigante comunicacional estimándose que en siete años se contará con mil millones de usuarios.
Pero sin marearse con tanta estadística y mejor vamos a lo concreto: reconocer que nuevamente la Internet nos trae sorpresas. Con los avances de infraestructura en estas tecnologías, los nuevos modos de programación y los nuevos modelos en su uso, han llegado también nuevas formas de denominar a este gran protagonista, y es aquí precisamente en donde comenzamos a entablar la denominación del “Cloud Computing” o Nube Computacional (o Computación en la Nube si queremos una traducción mas purista), la cual representa un nuevo punto de inflexión para el valor de las redes computacionales, prometiendo un gran cambio no solo en la industria informática si no también en la manera en que opera la gente en sus trabajos y compañías por la gran cantidad y variedad de servicios que están apareciendo día a día.
Complementando lo anterior, podemos fácilmente reconocer que cada época tiene sus palabras de moda, y la industria informática no es indiferente a este fenómeno. En los ochenta, la palabra de moda fue «multimedia»; en los noventa, «interactivo»; y en los últimos años, “Web 2.0”. Y justo cuando todos empiezan a sentirse cómodos con el último término de moda, aparece otro la ya nombrada Nube Computacional, y tal como las nubes mismas, parece ser un concepto nebuloso.
Acerquémonos un poco y veamos que no es tan nebuloso el tema, aclarando algunas ideas y
confusiones que de seguro a mas de alguno le han dado un dolor de cabeza.
¿QUE ES LA COMPUTACION EN LAS NUBES?
La característica básica de la computación en la nube es que los recursos y servicios informáticos, tales como infraestructura, plataforma y aplicaciones, son ofrecidos y consumidos como servicios a través de la Internet sin que los usuarios tengan que tener ningún conocimiento de lo que sucede detrás. Esto debido a que los usuarios no tienen idea alguna sobre la infraestructura que opera para ofrecer los servicios es que se llama Computación en las Nubes.
ARQUITECTURA DE LA CAPA DE SERVICIOS
Podemos dividir la Computación de las Nubes en las siguientes capas:
· Software como Servicio (SaaS)
Esta en la capa mas alta y consiste en la entrega de una aplicación completa como un servicio.
El proveedor SaaS dispone de una aplicación estándar desarrollada en algunos casos por él mismo
que se encarga de operar y mantener y con la que da servicio a multitud de clientes a través de la red, sin que estos tengan que instalar ningún software adicional. La distribución de la aplicación tiene el modelo de uno a muchos, es decir, se realiza un producto y el mismo lo usan varios clientes. Los proveedores de SaaS son responsables de la disponibilidad y funcionalidad de sus servicios no ejando de lado las necesidades de los clientes que son, al fin y al cabo, los que usaran el software.
Un ejemplo claro es la aplicación para el manejo del correo electrónico (como Gmail, Hotmail, Yahoo,
etc) por medio de un web-browser.
Plataforma como Servicio (PaaS)
PaaS es la siguiente capa. La idea básica es proporcionar un servicio de plataforma que permita desarrollar software a través de la red. El proveedor es el encargado de escalar los recursos en caso de que la aplicación lo requiera, del rendimiento óptimo de la plataforma, seguridad de acceso, etc. Para desarrollar software se necesitan, BBDD, servidores, redes, y herramientas de desarrollo. Con PaaS uno se olvida del personal para su uso y te centras en innovar y desarrollar ya que el hardware necesario para el desarrollo de software es ofrecido a través de Internet, lo que permite aumentar la productividad del los equipos de desarrollo. Un ejemplo es Google Aps Engine que permite desarrollar, compartir y alojar aplicaciones Web de terceros en su vasta infraestructura.
· Infraestructura como Servicio (IaaS)
IasS corresponde a la capa mas baja. La idea básica es la de externalización de servidores para espacio en disco, base de datos, routers, swtiches y/o tiempo de computación en lugar de tener un servidor local y toda la infraestructura necesaria para la conectividad y mantenimiento dentro de una organizaron. Con una IaaS lo que se tiene es una solución en la que se paga por consumo de recursos solamente usados: espacio en disco utilizado, tiempo de CPU, espacio en base de datos, transferencia de datos. Las IaaS permiten desplazar una serie de problemas al proveedor relacionados con la gestión de las máquinas como el ahorro de costos al pagar sólo por lo consumido y olvidarse de tratar con maquinas y su mantenimiento. Por otro lado IaaS puede permitir una escalabilidad automática o semiautomática, de forma que podamos contratar más recursos según los vayamos necesitando. Ejemplos de sitios son muchos esta el caso de Dropbox y SkyDrive. Estos sitios permiten alojar datos en servidores y accesar a ellos a través de cualquier parte del mundo con Internet.
VIRTUALIZACION EN LAS NUBES
La virtualizacion es esencial en el desarrollo óptimo de la computación en las nubes, y esta referida principalmente al tema de plataforma. Se puede decir que la virtualizacion es una abstracción de los recursos tecnológicos que permite a los servidores crear dispositivos virtuales la cual pueden ser usados para aumentar los recursos más que como sistemas discretos. En la computación en las nubes es interesante el tema de la para virtualizacion que permite tratar a un servidor como muchos servidores. Otro tema interesante es el clustering , que permite tratar a muchos servidores como uno solo. Esto permite muchos mejoramientos como:
– Rápida incorporación de nuevos recursos para los servidores virtualizados.
– Reducción de los costes de espacio y consumo.
– Administración global centralizada y simplificada.
– Mayor facilidad para la creación de entornos de test que permiten poner en marcha nuevas aplicaciones sin impactar a la producción, agilizando el proceso de las pruebas.
– Aislamiento: un fallo general de sistema de una máquina virtual no afecta al resto de máquinas virtuales.
– No sólo aporta el beneficio directo en la reducción del hardware necesario, así como de sus costes asociados.
ronaldcharca 