Mostrando entradas con la etiqueta Arquitectura del Software. Mostrar todas las entradas
Mostrando entradas con la etiqueta Arquitectura del Software. Mostrar todas las entradas

viernes, 15 de febrero de 2013

Más allá del misterio: Asignando valores con el Revealing Module Pattern

Un patrón bastante extendido cuando desarrollamos código en JavaScript es el Revealing Module Pattern para poder establecer ámbito sobre ciertas partes de nuestro módulo. Quien más quien menos que desarrolle en JavaScript (y no esté en una cueva) ha oído hablar de él así que no vamos a hacer un análisis en detalle sobre el mismo.
Por otro lado, es bastante común exponer un objeto con los nombre de las propiedades que coincidentes con los métodos y propiedades que exponemos y aquí viene el punto propenso a errores que quiero mitigar con este post.
Imaginemos este código:
   1:  var Person = function () {
   2:      var name,
   3:          sayHello = function () {
   4:              alert('Hi, my name is ' + name);
   5:          };
   6:      return {
   7:          name: name,
   8:          sayHello: sayHello,
   9:      }
  10:  }
  11:   
  12:  var andoni = new Person();
  13:  andoni.name = 'andoni';
  14:  andoni.sayHello();



Si yo os pregunto que mostrará la función sayHello por pantalla, que me diríais?
Pues aunque no os lo creáis un bonito mensaje: "Hi, my name is undefined"
Ahora es cuando viene lo de:

“¿Pero que ha pasado? Si yo he asignado el name a "Andoni"!!!

Esto seguro que es por lo del this, o lo del lexical scope … JavaScript es un mierda y que porque no nos habremos quedado en la era de COBOL...”

Que no cunda el pánico, vamos a entender que ha pasado antes de pegarle fuego a V8, Chakra y a todo lo que se mueva...

Tened en cuenta que si aplicamos el patrón, la función nos devuelve otro objeto con dos propiedades (name y sayHello). Cada una de ellas apunta a los objetos reales que está revelando. El código que hemos visto arriba recibe ese objeto y lo que está haciendo es cambiar a que apunta la propiedad name del objeto revelado, que obviamente, no es lo que esperábamos... (recordad los punteros)

Revisemos nuestro código problemático con una modificación:

   1:  var Person = function () { 
   2:      var name, 
   3:          setName = function(nameToSet){ 
   4:              name = nameToSet; 
   5:          }, 
   6:          sayHello = function () { 
   7:              alert('Hi, my name is ' + name); 
   8:          }; 
   9:      return { 
  10:          name: name, 
  11:          setName: setName, 
  12:          sayHello: sayHello, 
  13:      } 
  14:  }
  15:   
  16:  var andoni = new Person(); 
  17:  andoni.setName('andoni'); 
  18:  andoni.sayHello();



Ahora si que recibiremos el mensaje esperado, debido a que la modificación se esta realizando sobre el mismo objeto y no sobre la propiedad del proxy que nos está siendo revelado.

Es un problema sutil y en ocasiones difícil de corregir así que espero que les sea de utilidad.

Un saludo desde Seattle!!

Andoni Arroyo

martes, 31 de enero de 2012

Invocando un servicio WCF desde una aplicación Metro (desde la misma máquina!!)


El otro día hablábamos de las limitaciones de comunicación entre aplicaciones Metro y Desktop hospedadas en la misma máquina establecidas en Windows 8. De hecho, hablábamos de la “NO” comunicación entre Metro y Desktop. Los pistoleros más rápidos dirán que donde dije Digo ahora digo Diego, pero esperar un poco antes de apedrearme en la plaza pública…

Comentábamos que por diseño, invocar desde una aplicación Metro a un servicio WCF expuesto en la misma máquina, no está permitido. Esto puede ser una restricción demasiado estricta (y totalmente injustificadas) si estamos desarrollando en la misma máquina el servicio y la parte Metro que la consume.

Para este tipo de casos (y no para saltarnos el control, que no tenéis una idea buena...) contamos con una herramienta de línea de comandos llamada CheckNetIsolation. Podemos leer un poco más al respecto aquí http://msdn.microsoft.com/en-us/library/windows/apps/hh452759.aspx

Acorde a dicha restricción, al acceder a dicho servicio, la aplicación Metro (sin ningún tratamiento previo) recibiremos una excepción del tipo EndPointNotFopundException con un mensaje tal que así:

{"There was no endpoint listening at ... that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details."}

Ok, a menos de que creas que la gente de Microsoft va de farol, es lo esperado, no?

Ahora viene lo interesante. Para permitir este tipo de comunicación (recuerda que la limitación solo se aplica a la misma máquina) debes seguir estos pasos:

Lo primero que debemos hacer es buscar en el registro la clave de la aplicación Metro con la que deseamos hacer la excepción. Para ello, abrimos el Regedit y buscamos la clave de la aplicación que cuelga de:

HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer

Fíjate en el valor de la propiedad displayname para poder identificarla.
Una vez que sepamos la rama concreta, puedes seleccionarla con el botón derecho y copykeyname y selecciona el nombre de la carpeta del mapping (desde S-1-15... hasta el final). Este <keyname> nos permitirá establecer la excepción más adelante.

A continuación, abre el “Developer Command Promp” y escribe “CheckNetIsolation” para acceder a la utilidad. Pégate una leidita el enlace anterior para evaluar un poco mas en detalle las capacidades de la herramienta.

En nuestro caso debemos escribir:

  • Para ver el listado de las aplicaciones ya excluidas del bloqueo de loopback:
    CheckNetIsolation.Exe LoopbackExempt –s
  • Para incluir nuestra aplicación como una excepción:
    CheckNetIsolation.exe LoopbackExempt -a -p=<keyname>
  • Para comprobar que ya ha sido correctamente incluida, pues vuelve a ejecutar el comando anterior (nunca te lo hubieses imaginado, verdad?)
    CheckNetIsolation.Exe LoopbackExempt –s

Una vez hecho esto, ya podremos consumir servicios de la misma máquina sin recibir la excepción comentada al principio del post, comprobado!!

miércoles, 25 de enero de 2012

Windows 8 y la “NO” comunicación entre Metro y Desktop

Windows 8 va cogiendo forma, y lo que vamos viendo nos confirma que la gente de Redmond está haciendo una apuesta muy fuerte por evolucionar su sistema hacia diferentes dispositivos. Un único sistema operativo para ordenadores y tabletas (dejemos los teléfonos de momento…) implica un profundo replanteamiento del mismo, desde sus cimientos.

Por un lado tenemos un gran hito para Windows 8 es la necesidad de correr sobre procesadores ARM. Por otro lado, Microsoft tradicionalmente se aplica en  maximizar la compatibilidad hacia atrás. Este es un compromiso que tradicionalmente le ha diferenciado de la competencia digamos más “intrépida” en sus evoluciones/revoluciones.

El resultado de aplicar este par de fuerzas, en principio opuestas (compatibilidad hacia atrás VS evolución hacia la ligereza) implica casi tener dos sistemas operativos en uno. Es muy interesante la lectura de este post Windows 8 – A Tale of Two Platforms al respecto.

Siempre que se produce un cambio profundo como este, se generan por un lado un buen montón de riesgos a mitigar así como otro montón de oportunidades a aprovechar. Cuando comenzamos a evaluar la posibilidad de que nuestras aplicaciones corran sobre Windows 8 siempre comenzamos a pensar en los componentes que la conforman y en como ir migrándolos hacia la nueva plataforma.

Quien más quien menos ha oído o va a oír al respecto:
“Este servicio lo dejo igual y desde la interfaz metro lo invoco y...”

Pero en esta aproximación hay un demonio escondido: crea un dependencia de la parte de aplicaciones “Metro” hacia la parte “Desktop” y ese no es el camino que Microsoft fomenta. Tengamos en cuenta que si todos los desarrolladores aplican ese proceso, la parte “Metro” de Windows 8 nunca podrá correr sin la parte “Desktop”. Ese es el precio a pagar por dicha dependencia.

Podemos ver esta división en el siguiente gráfico:
image

Comprobamos que no existe un canal de comunicación oficial por encima del Kernel de Windows (que obviamente, comparten) para realizar comunicaciones entre aplicaciones “Metro” y “Desktop”.

La pregunta (muy común y cada vez más) es clara:
¿Como puedo comunicar entre aplicaciones Metro y Desktop?

La respuesta no es tan clara, pero desde luego no es algo que en principio Microsoft fomente.
El modelo de procesamiento en la nube y clientes ligeros es el candidato por todas las grandes a la hora de llegar a diferentes dispositivos y es también es el que Microsoft promociona. Este escenario ha demostrado su éxito en la competencia y algo sabe esta empresa de aprender de los demás.

Una posible solución (por supuesto depende de la naturaleza de cada aplicación) es llevar toda la lógica de tu aplicación a tu proveedor de Cloud (Azure, Amazon, GAE…) y dejar un cliente bien ligero en “Metro” que consuma de manera optimizada dichos servicios. (Debemos tener en cuenta que en Metro solo se ha migrado la parte de cliente de WCF!!).

Obviamente este modelo también tiene su problemática a resolver, como por ejemplo como comportarse en caso de no tener comunicación.
Con el fin de confirmar las limitaciones de comunicación entre aplicaciones “Metro” y “Desktop” podemos leer:

  • Ale Contenti comentaba que la comunicación entre aplicaciones de ambos mundos es a nivel de archivo. (aunque también dice que es muy pronto para confirmarlo)
    http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C
  • Otra idea podría ser montar un Servicio Web en la parte Desktop:
    Respecto a eso, podemos leer a Jeff Sanders en los foros de soporte de Microsoft:

    “You cannot access a WebService on the same machine. The WebService would need to be external to the machine ... In Metro you cannot use IPC except with Metro Style applications that are in the same package.”Otro día hablamos de CheckNetIsolation.exe, prometido!
  • Pero estas restricciones de comunicación no solo existen a alto nivel. Podemos leer a Pavel Minaev:

    ”… Named pipes aren't there, for example, nor are memory mapped files. There are sockets (including server sockets), but when connecting to localhost, you can only connect to the same app. You could use normal files in one of the shared "known folders" (Documents, Pictures etc), but that is a fairly crude hack that necessitates polling and is visible to the user.”

A buen entendedor pocas palabras bastan. Podemos ver claro que este canal de comunicación no es el deseado. Y esto es comprensible, puesto que si pensamos un poco en los diferentes escenarios sobre los que deseamos corra Windows 8 podemos observar que:
  • PCs Legacy corriendo Windows 8 donde se ejecutarán aplicaciones Legacy pero no van a aprovechar las bondades de las aplicaciones basadas en interfaces táctil (Metro/WinRT)
  • Tabletas x86 donde podrán correr aplicaciones Legacy que por otro lado, si sacaran el máximo a las aplicaciones metro. Eso si, tendremos que tener en cuenta temas como peso, vida de la batería, coste...
  • Tabletas basadas en ARM donde las aplicaciones Legacy (salvo que Microsoft se saque algo de la chistera...) no van a correr, pero sacarán el máximo de Metro.
Resumiendo podemos decir que Windows 8 tiene dos caras, es muy importante comprender esto para poder afrontar las migraciones y nuevos desarrollos con la perspectiva adecuada al nuevo panorama que se nos presenta.

domingo, 25 de julio de 2010

SOA != Client Server + WCF

El panorama actual en el mundo de desarrollo del software nos brinda más oportunidades de las que nunca habíamos tenido (quizás ni siquiera imaginado). Entre otros escenarios, la aparición de Internet ha propiciado el crecimiento de los sistema distribuidos, la orientación a servicios, el SaaS...

Este nuevo "el dorado" plantea características donde todas las empresas desean desembarcar sus activos. Por supuesto estos destinos son tan interesantes que muchos deciden tomar atajos para llegar a lo que creen el mismo destino, pero cuidado,
que como siempre, no es oro todo lo que reluce.

La formula del título viene a decir eso, se podría leer como:

SOA != Client Server + WCF

No es lo mismo desarrollar Software orientado a servicio que colocar una capa de WCF en una aplicación Cliente Servidor. Definitivamente NO ES LO MISMO...

Pero como ya sabemos las cosas no cambian solas, debemos como desarrolladores hacer un esfuerzo por ser conscientes de las nuevas reglas de juego con las que deseamos que nuestras aplicaciones den la talla.

Revisando mi experiencia el respecto podemos identificar los errores más comunes a la hora de crear Software orientadas a servicios:

  • Los servicios (aunque no te lo creas) no están (solo) para ti.
    Utiliza los recursos del servicio de manera razonable, piensa bien como y cuando realizar las llamadas evitando acaparar los recursos disponibles.
  • Al consumir otros servicios estas realizando una llamada remota, eres consciente?
    No hagas 17 peticiones con sus 17 serializaciones para pintar una pantalla. No me digas que son las clases que usas como DTO y que te van para el pelo para tu ORM...
    Todo el tiempo invertido en optimizar la comunicación tendrá un alto ROI, te lo aseguro.
    Por supuesto recibir 26 millones de objetos (bien serializados) es un problema a nivel de diseño de la aplicación. (consolida la información, pagina, trabaja por bloques pero no tires por ese camino bajo ningún concepto...)
  • Siempre piensa en que la disponibilidad nunca es del 100%
    Eso es así aunque algún comercial se empeñe en decir lo contrario.
    Pregúntate que ocurre si el servicio no está disponible y dota a tu aplicación de la inteligencia necesaria para responder ante tal situación de manera digna. Siempre es interesante valorar la posibilidad de realizar las comunicaciones de manera asíncrona.
    Ten en cuenta que no debes lanzar procesos que comprometan la estabilidad de los servicios, puesto que estos deben estar disponibles para los demás clientes.
    (Recuerda que trabajar por bloques "casi nunca" es opcional y con determinado volumen de datos es obligatorio)
    Piensa en la Alta disponibilidad, como hacer correr varias instancias en paralelo, clúster activo-pasivo antes de que te pille el toro...
  • Diseña un plan de contingencia y déjalo por escrito
    Si no quieres que la gente que mantiene la aplicación te llamen a las 3:00 de la madrugada por que se ha parado el servicio, dales los mecanismos oportunos para que operen con autonomía. Ten un poco de empatía y piensa que ellos no pueden controlar todas las aplicaciones que están en producción como los que lo han desarrollado. 
  • Escalabilidad no es solo una palabra más terminada en …idad
    Creo que está de más decirlo, pero evitar mantener el estado en el servidor entre tus llamadas te permitirá escalar mejor. Tomate la molestia de planificar mecanismos de escalabilidad vertical y horizontal si no quieres morir de éxito. Corregir este tipo de problemas a posteriori siempre es traumático.
    Ten en cuenta que todos los recursos son limitados, hasta el disco donde escribes el log se acaba si no tienes políticas de reciclaje. Piensa en que los servicios están diseñados para ejecutarse 24x7 y 365 días al año, en estos detalles debemos hacer especial énfasis.
  • La correcta gestión de excepciones te puede salvar la vida
    En relación con la disponibilidad, es crítico gestionar de manera lo más eficiente posible las excepciones. La tecnología está ahí hace tiempo solo debes esforzarte en aplicarla correctamente. Una excepción en un servicio debe gestionarse correctamente para que no comprometa su estabilidad y disponibilidad. Trabajar sobre ello puede mejorar mucho la QoS y reducir el coste de mantenimiento.
  • Invierte tiempo en pensar bien tus contratos
    Es importante ajustar el equilibrio entre la cohesion de los servicios y los clientes. Cuando desarrollamos orientado a servicio no debemos hacerlo ad-hoc a un cliente en particular. El servicio debe exponer una serie de funcionalidades bien definidas. Extendiendo esta característica conseguimos el correcto grado de cohesión.
    Ahora tampoco hagas que usar tus servicios sea un infierno...
  • Piensa bien cual es la mejor manera de establecer la comunicación con tus servicios
    La serialización y transporte de los objetos es una parte muy significativa del tiempo de procesamiento consumido. Piensa cuidadosamente la manera de exponer tus servicios al mundo. expón los endpoints que sean necesarios y afina los behaviors de los mismos para evitar matar moscas a cañonazos.

Como siempre, se hace camino al andar, así que la resolución de los problemas presentes en este tipo de escenarios también tenderá a converger (para estandarizarse más adelante) mientras todos maduraremos en el proceso.

Por supuesto surgirán nuevos problemas relacionados con llevar el mundo del desarrollo de software más allá, que para algo estamos aquí, no?

martes, 18 de agosto de 2009

¿Es lo mismo arquitectura por capas y N-Tier?

Me parece importante, para optimizar la comunicación entre profesionales, que todos tengamos claros los conceptos y los apliquemos para referirnos exactamente a lo mismo. Esto nos evita malas interpretaciones y errores muy críticos sobre todo en entonos de desarrollo rápido de aplicaciones (RAD). 

Existen dos conceptos arquitectónicos que a veces tendemos a confundir. Estos son la “Layered arquitecture” (arquitectura por capas) y la “N-tier arquitecture” (arquitectura de N-niveles). Me voy a referir a ellas sin traducirlas, puesto que ambos conceptos (“layer” y “tier”) pueden verse traducidas (erróneamente en el caso de “tier”) como “capa” lo cual fomenta aún más la propensión a errores.

Veamos primero que es exactamente “Layered architecture”: 

Se centra en una distribución jerárquica de las roles y responsabilidades proporcionando una separación efectiva de las preocupaciones. (cada cual que se apañe con sus problema…). El rol indica el modo y el tipo de interacción con las otras capas, y la responsabilidad indica la funcionalidad a alcanzar.

Por ejemplo, el diseño de una típica aplicación Web comprende una capa de presentación (funcionalidad relacionada con la U.I.), capa de negocio (procesamiento de reglas de negocio) y capa de datos (funcionalidad relacionada con el accesos a datos.)

El estilo de arquitectura por capas tiene algunas características que  la identifica:

  • Describe una descomposición de servicios de tal manera que las interacciones ocurren normalmente entre capas vecinas. (depende de lo laxos que queramos ser…)
  • Las capas de la aplicación pueden residir en el mismo ordenador fisco o pueden estar distribuidas en separados equipos. El concepto de distribución se aplica siempre que se produzca el mecanismo de marshaling para realizar una comunicación (siempre que no se comparta espacio de memoria…)
  • Los componente de cada capa se comunican con otros componente de otras capas a través de un conjunto de interfaces bien definidos. (sino apañados vamos…)
  • En alguna ocasión ha sido descrito como “pirámide invertida de reutilización” donde cada capa agrega sus propias responsabilidades  y abstracciones a la capas que están por debajo.

Que beneficios conseguimos aplicando esta distribución en capas?

Abstracción, encapsulamiento, capas de funcionalidad muy bien definidas, alta cohesión, reusabilidad (las capas inferiores de la pirámide no tienen dependencias de las superiores por lo que es fácil reutilizarlas) y débil acoplamiento (comunicación basada en abstracciones)

La separación, reduce el riesgo y el impacto de los cambios tecnológicos. Por ejemplo al cambiar el mecanismo de persistencia de la aplicación las capas que lo consumen no tienen porque realizar cambios. Además aumenta el rendimiento (a partir de cierta carga de trabajo) al distribuir las capas sobre múltiples capas físicas. También aumenta la escalabilidad y la tolerancia a fallos.

Este escenario es propicio para implementar una buena política de pruebas, permitiendo conmutar entre diferentes implementaciones de los interfaces (mock, servicios reales…)

Por otro lado tenemos la “N-Tier architecture”

El estilo de despliegue de esta arquitectura describe la separación de la funcionalidad en diferentes segmentos, de manera similar a la arquitectura por capas. pero cada segmento es un nivel que se encuentra físicamente en un equipo independiente.

Es un estilo que define el despliegue de las capas de la aplicación, se caracteriza por por una descomposición funcional de la aplicación, componentes de servicios y su despliegue distribuido, proveyendo mejoras de escalabilidad, disponibilidad  y utilización de recursos.

Cada capa es completamente independiente del resto, excepto de aquella/s se encuentran inmediatamente por debajo de ella. La capa n sabe como manejar las peticiones a la capa n+1, como trasladar dicha petición a la capa n-1 (si es que existe) y como tratar el resultado de la misma.

Las arquitecturas con “N-Tiers” poseen por lo menos 3 capas lógicas separadas. Cada capa tiene una funcionalidad especifica, de la cual es responsable y están localizadas en diferentes servidores físicos. Una capa (“layer”) se despliega en un nivel (“tier”) si más de un servicio o aplicación es dependiente de la funcionalidad expuestas por la capa.

Veamos los beneficios que nos aporta esta arquitectura:

  • Mantenibilidad
    Cada nivel es independiente de los demás, con lo que se consigue independencia. Se puede actualizar o modificar un nivel sin afectar a la aplicación en su conjunto. 
  • Escalabilidad
    Es razonablemente sencillo escalar puesto que los niveles están basadas en el despliegue de las capas.
  • Flexibilidad
    Cada nivel puede ser gestionado o escalado independientemente, lo cual aumenta la flexibilidad.
  • Disponibilidad
    Las aplicaciones pueden explotar la arquitectura modular empleando componentes fácilmente escalables.

Resumiendo un poco :

Podemos decir que para que una aplicación sea “N-Tier”, es condición necesaria pero no suficiente que mantenga una arquitectura por capas. Esta característica nos permite cumplir los requisitos de despliegue (3 o más capas separadas) que hacen a una aplicación “N-Tier”.

martes, 27 de mayo de 2008

Entity Framework SP1 (o como no debe usted implementarse su propio O.R.M. a estas alturas...)

Con el reciente lanzamiento de la Beta del Visual Studio 2008 SP1 por parte de Microsoft me he decidido a investigar la nueva versión del Entity Framework que en el se incluye. Tengo que decir que aunque la cosa todavía esta un poco verde promete.

Se caia de maduro que Microsoft necesitaba cubrir un nicho en la que las soluciones de terceros (Hibernate, Neo, Codus...) se le habian colado en su bonito .NET Framework: Los Object Rational Mapping (ORM) y los servicios de consultas contra dichos objetos.

Microsoft ha realizado intentos, timidos pasos hacia lo que hoy es (o mejor dicho mañana será) el Entity Framework. Se probó con el DataSet, que prometia ser la revolución y se quedo por el camino, muy mal acompañado del XSD para definir modelos. Las especificaciones completas de XSD además de ser infumables, se olvidan por completo de hablar de servicios como la persistencia. Así que no es el lenguaje optimo para hablar de entidades que queremos trabajen con el ORM.

De hecho, existe una nueva especificación para definir los modelos conceptuales (CSDL), de almacenamiento (SSDL) y mapeo el E.D.M.(Entity Data Model). Dichas especificaciones cubren ambos mundos de manera muy natural (puesto que para eso ha sido creado, dicho sea de paso)

Disponer de un ORM (entre otras funcionalidades) estandar y mantenido por Microsoft es un tema a tener muy en cuenta. Yo por mi cuenta, me cree hace un par de años una implementación propia de un ORM común para mis proyectos. Pero no solo yo, es que casi todos los colegas con cierta carga de proyectos se han ido haciendo las suyas propias formando una torre de Babel de lo más poco práctica.

Y el problema no solo es hacerlo sino mantenerlo (y más rápido que Microsoft) desviando esfuerzo de la implementación de sus propias aplicaciones. Por eso es tan interesante el Entity Framework.

Por supuesto, existe la guinda del pastel en forma de LINQ to Entities que es una implementación del proveedor de LINQ para trabajar contra objetos de tipo Entidad (Definidos en el E.D.M.) e incluso una implementación de SQL llamada eSQL(subconjunto muy limitado (sin instrucciones DML para la release 1)) para atacar directamente al nuevo cliente EntityClientProvider que se coloca sobre los proveedores de todas la vida, abstrayendo de sus particularidades.

En este aspecto coincidimos todos los que "parimos" cualquier implementación mejor o peor (que de todo hay no se vayan a crerer) de ORM, en cuanto madure un poco, al trastero con las soluciones propias y a trabajar con el Entity Framework.

Como ven hay muchas cosas interesantes pero ya las iremos viendo poco a poco.

Un saludo.

Razones para evitar la programación en cliente en Aplicaciones Web

Existen algunas razones para intentar evitar la programación en el lado del cliente:
  • Aislamiento
    El código del lado del cliente no puede acceder a los recursos del servidor. Por ejemplo, una aplicación que se ejecuta en el cliente no tiene una manera sencilla de leer un fichero o interactuar con una base de datos del servidor (al menos no sin caer en problemas con la seguridad y compatibilidad de navegadores)

  • Seguridad: Los usuarios finales pueden ver el código de cliente. (Y cuando digo pueden es SIEMPRE pueden solo varia el tiempo que tienes que invertir en poder ...) Por lo tanto un usuario malintencionado al entender como funciona la aplicación puede "trampearla" más a menudo.
Un saludo

domingo, 20 de abril de 2008

Definición de la Arquitectura del Software

"La arquitectura del software es un conjunto de decisiones de diseño, que tomadas de forma errónea, pueden hacer que un proyecto sea cancelado”

Eoin Woods

Instituto de Ingeniería del Software CarniegeMellon

lunes, 17 de marzo de 2008

Windows Communication Foundation (1)

El W.C.F. (no confundir con el W.T.F.! ;)) es el núcleo de las aplicaciones de comunicación orientadas a servicio (service-oriented) para la plataforma Windows.

Se coloca sobre los estándares de Servicios Web y está diseñada para las necesidades de la arquitectura orientada a servicio (S.O.A.) y el Software como servicio (Software As A Service (SAAS)) (Perdón por la anidación...)

Esta filosofía establece que el software debe ser construido alejado del "grano fino", con componentes débilmente acoplados y con interfaces bien definidas que se comuniquen empleando protocolos estándar.

Los Servicios Web fueron el principio de esta tendencia, donde la lógica de negocio de una manera independiente de la tecnología, exponiendo un interfaz basado en XML utilizando un lenguaje llamado Web Services Description Language (W.S.D.L.). Los desarrolladores pueden entonces emplear un mensaje XML con un formato llamado Object Access Protocol (S.O.A.P.) (Jabón para los profanos...) que deriva de XML para comunicar con el Sevicio.

Seguiremos profundizando...

Un saludo

miércoles, 12 de marzo de 2008

Arquitectura de capa de presentación: Del ayer al mañana (II)

Como los ordenadores se hicieron mas sofisticados, las tarjetas perforadas dejaron paso a los terminales que adquirían y mostraban los resultados del servidor central.


Arquitectura de petición-respuesta basada en terminal

Para un procesamiento muy básico este modo de proceder era útil, pero los requisitos de las aplicaciones informáticas son cada vez más sofisticados, como el correo electrónico, news... para los cuales dichos terminales se han quedado pequeños.

Pese a esto, es común observar en grandes almacenes o grandes tiendas de venta al público, que las cajas siguen funcionando con terminales poco más sofisticados que estos, donde todos los procesos se ejecutan en el servidor pese a tener un PC en la caja con la suficiente capacidad para desarrollar otras tareas. (Upsizing? otro día hablaré de ello...)

Si recuerda algun viejo programa de correo electrónico para terminales como "eml" también recordará la necesidad de tres o cuatro dedos extra para hacer cualquier cosa útil.

Desde el punto de vista de la arquitectura, este escenario no difiere mucho del de las tarjetas perforadas, pero unifica el punto de contacto con el mainframe y cambia el medio del papel a los electrones. Pese a que la arquitectura no cambia la implementación si lo hace y fue este cambio de implementación un factor que encaminó la mejora global de la experiencia de usuario, un hecho que continua hoy en día.

martes, 11 de marzo de 2008

Arquitectura de capa de presentación: Del ayer al mañana (1)

El interfaz de usuario a evolucionado a lo largo de un camino cíclico que abarca desde los clientes ligeros hasta los pesados y vuelta a empezar.

Por un lado, los requisitos de los usuarios así como las demandas de funcionalidad extra conducen al tipo de cliente pesado. Por otro lado, los requisitos y demandas relativas a la facil instalación, actualización y mantenimiento nos conducen a los clientes más ligeros.

Con cada iteración el interfaz de cliente "más ligero" gana funcionalidad y el "más pesado" se vuelve más fácil de instalar, actualizar y mantener.

El interfaz de usuario original fue probablemente el cliente más ligero de todos. Las tarjetas perforadas que se enviaban al servidor central que devolvía los resultados impresos.

Arquitectura simple de petición-respuesta

miércoles, 13 de febrero de 2008

Confiabilidad

El proceso de diseñar para confiabilidad implica revisar el patrón de uso esperado de la aplicación, especificando el perfil de confiabilidad requerido e ingeniando la arquitectura del software con la intención acomodarse al perfil.

Tareas:

  • Especificar los requisitos de confiabilidad en la especificación.
  • Emplee una buena infraestructura arquitectónica.
  • Incluya información de mantenimiento en la aplicación.
  • Emplee redundancia.
  • Use herramientas de desarrollo de calidad.
  • Emplee comprobaciones de confiabilidad que son provistas por la aplicación.
  • Emplee una manipulación de errores consistente.
  • Reduzca la funcionalidad de la aplicación para conseguir la aplicación libre de defectos en vez de completa pero con errores.

El rendimiento de una aplicación se define en base a unas métricas claves, como son el rendimiento de las transacciones y la utilización de recursos. Para determinar el objetivo de rendimiento debe responder a algunas preguntas como las siguientes:

  • ¿Cual es el objetivo de negocio?
  • ¿Cuál es la funcionalidad clave de la aplicación?
  • ¿Cuáles son las características requeridas por los diferentes conjuntos de usuarios?
Un saludo.

lunes, 11 de febrero de 2008

Escalabilidad y disponibilidad

Veamos a aclarar algunos aspectos importantes a la hora de evaluar la planificación de una aplicación, como son la escalabilidad y la disponibilidad.

La escalabilidad se define como la capacidad de incrementar recursos para producir un incremento lineal en la capacidad del servicio. A una aplicación se le puede hacer scale-up o scale-out

Las directrices para el escalado:

  • Diseñar procesos que no esperen.
  • Diseñar los procesos de tal manera que no peleen por los recursos.
  • Diseñar procesos conmutables.
  • Diseñar componentes intercambiables.
  • Partición de recursos y actividades.

Disponibilidad es la medida de cuan a menudo una aplicación esta disponible parar su uso. Para decidir el nivel de disponibilidad de una aplicación debe responder a las siguientes preguntas:

  • ¿Quién es el cliente y cuales son sus expectativas?
  • ¿Cuánto tiempo de “no disponibilidad” es aceptable?
  • ¿Hay procesos internos de la compañía que dependen de la aplicación?
  • ¿Qué calendario y presupuesto de desarrollo tiene la aplicación?

Las directrices para diseñar pensado en disponibilidad son:

  • Reducir el tiempo planificado de “no disponibilidad”.
  • Reducir el tiempo no planificado de “no disponibilidad” utilizando Clustering.
  • Utilizar balanceo de carga.
  • Utilizar RAID para el almacenamiento de datos.
  • Aísle las aplicaciones de misión crítica.
  • Utilice colas de mensajes.

Un saludo.

viernes, 1 de febrero de 2008

Certificación 70-300 "Analyzing Requirements and Defining Microsoft .NET Solution Architectures"

Hoy he superado con éxito el examen de certificación de Microsoft 70-300 de nombre:

"Analyzing Requirements and Defining Microsoft .NET Solution Architectures"

La llevaba preparando unos meses (tengo poco tiempo para estudiar). El material de preparación es bastante interesante y se centra en el desarrollo de soluciones informáticas desde la perspectiva de la organización, toma de requisitos, metodología de desarrollo, arquitectura de la solución...

Un tema interesante, la verdad.

miércoles, 30 de enero de 2008

Diseño de especificaciones de seguridad (3 de 3)

Unos conceptos muy importantes relacionados con la seguridad son los de autenticar (demostrar que se es quien se dice ser) y autorizar (establecer que puede y que no puede hacer el usuario por ser quien es)

Para diseñar una estrategia de autenticación y autorización se necesita:

  1. Identificar los recursos.
  2. Seleccionar la estrategia de autorización.
  3. Seleccionar las identidades empleadas para acceder a los recursos.
  4. Considerar el flujo de identidad.
  5. Seleccionar el enfoque de autenticación.
  6. Decidir como debe fluir la identidad.
Con esta triada damos por finalizado (de momento) este repaso a conceptos generales relacionados con la seguridad.

martes, 29 de enero de 2008

Diseño de especificaciones de seguridad (2 de 3)

Continuemos viendo las especificaciones de seguridad. Como hemos identificado en el post anterio existen diferentes tipos o categorias de amenazas. Su concimiento nos permite crear un plan o metodología para contemplar una posible respuesta a dichos tipos de amenazas.

Con el fin de tener un guión a la hora planificar esta tarea podemos identificar una serie de pasos para crear un modelo de amenazas son:

  • Organizar una reunión de tormenta de ideas.
  • Aplicar la organización de categorías de seguridad STRIDE.
  • Listar todas las posibles amenazas.
  • Crear apuntes.
  • Investigar.
  • Clasificar el riesgo de cada amenaza.
Por supuesto estas actividades deben tener su soporte tecnológico. Los grandes fabricantes de entornos de desarrollo están ampliamanete sensibilizados con los problemas de seguridad (más les vale) y portan tecnología out-the-box para la correcta gestión de la seguridad de las aplicaciones que sobre ellos se desarrollan.

Por ejemplo, las características de seguridad del Microsoft .Net Framework incluyen:

  • Validaciones de Tipo seguro
  • Firmado de código.
  • Encriptación y firmado de datos.
  • Seguridad de acceso al código.
  • Seguridad basada en roles.
  • Almacenamiento separado.

Finalizaremos en el siguiente post.

Diseño de especificaciones de seguridad (1 de 3)

Vamos a analizar algunos aspectos relativos a la seguridad de las aplicaciones. Primero veamos los tipos más comunes de vulnerabilidades de seguridad:

  • Contraseñas débiles.
  • Software des-configurado o mal configurado.
  • Ingeniería social.
  • Conexiones de Internet.
  • Transferencia de datos sin encriptar.
  • Desbordamiento de buffer.
  • SQL Injection.
  • Secretos en código.

El conocimiento de dichos tipos de vulnerabilidades nos permite realizar una planificación más detallada de los pasos a seguir y aspectos a tener en cuenta.

Los pilares para crear una estrategia de seguridad incluyen:

  • Confiar en sistemas de seguridad probados.
  • Nunca confiar en las entradas externas.
  • Asumir que los sistemas externos no son seguros.
  • Aplicar el principio de mínimos privilegios.
  • Reducir la disponibilidad de componentes y datos.
  • Colocar como modo por defecto el modo seguro.
  • No confiar en la seguridad por ocultación.
  • Seguir los principios de STRIDE.
Continuaremos con el siguiente post.

jueves, 24 de enero de 2008

Diseño de la capa de datos (3 de 3)

Más aspectos a tener en cuenta en la capa de datos:

  • La normalización es el proceso progresivo de refinamiento del modelo lógico con el fin de eliminar los duplicados y las mermas de espacio de la base de datos.

  • El resultado de la normalización es reducir las inconsistencias y hacer más rápida las modificaciones de los datos.

  • Denormalizar es el proceso de deshacer una normalización para generar tabas con más campos que requieran menos Joins lo que implique una mejora del procesamiento de las Querys.

  • La integridad de datos hace referencia a la consistencia y precisión de los datos.

    • La integridad de dominio especifica un conjunto de valores de datos legitimados para una columna y determina si el valor nulo será admitido.

    • La integridad de Entidad requiere que cada fila en una tabla posea un identificador único, conocido como el valor de clave primaria.

    • La integridad referencial asegura que las relaciones entre claves primarias y claves extranjeras son siempre mantenidas.

Diseño de la capa de datos (2 de 3)

Sigamos analizando aspectos importantes de la capa de datos:

  • Los tipos de datos especifican la clase del dato que será almacenado en un campo y como ese dato será representado.

  • Las claves únicas identifican cada instancia de una entidad dentro del modelo de datos.

  • Las claves extranjeras unen dos tablas en una base de datos.

  • Las relaciones entre las entidades se representan añadiendo las claves de una entidad en las otras tablas.

  • Para optimizar las prestaciones de una base de datos usted necesita:
    • Optimizar su base de datos.
    • Realizar pruebas de estrés a la aplicación.
    • Usar transacciones ajustadamente.
    • Comunicar efectivamente cruzando los limites.
  • Un índice es una lista ordenada de filas en una tabla que el DBMS puede emplear para acelerar las operaciones de búsqueda.

  • Puede optimizar la velocidad de procesamiento de tablas muy grandes participando sus datos, tanto vertical (de una tabla a varias con la misma clave primaria y diferentes columnas) como horizontalmente (de una tabla a varias que contengan las mismas columnas).
Continuamos en el próximo post.

Diseño de la capa de datos (1 de 3)

Vamos a comenzar una serie de posts dedicados a hablar de la capa de datos en la arquitectura de tres capas tradicional. (Datos, negocio y presentación)

En la fase de planificación de la M.S.F., el equipo del proyecto analiza los requisitos de la solución y especifica como los datos serán estructurados, almacenados, accedidos y validados.

Algunos aspectos a tener en cuenta son:

  • Un esquema de base de datos refleja las entidades del problema, los atributos de dichas entidades así como las relaciones entre dichas entidades.

  • El modelo físico de datos de un DBMS define la estructura interna que dicho DBMS para mantener la gestión de dichos datos.

  • Los tres modelos físicos de datos que se emplean normalmente son los ficheros planos, el modelo jerárquico y el modelo relacional.

  • Las entidades y atributos que se derivan durante el diseño lógico son “mapeadas” por las tablas, campos y relaciones en la base de datos.

  • Las tablas son la representación física de las entidades en una base de datos relacional.

  • Las columnas son la representación física de las propiedades en una base de datos relacional.
Seguimos en el próximo post.