02.23.10
Posted in Arquitectura at 3:04 pm by Miguel
Desde hace unos años atrás los entornos virtualizados se abren camino y cada día se encuentran presentes con mayor frecuencia en el mundo del desarrollo de aplicaciones.
La virtualización presenta una mejora principal que es el ahorro de costes asociado a la compra de servidores. Ya no va a ser necesario comprar n máquinas encargadas de soportar servidores web, servidores de base de datos, servidores de ficheros, correo electrónico. Cada máquina viene a representar un coste en Hardware más que significativo. Con la virtualización es posible disponer de un único soporte hardware que albergue n servidores virtualizados a nivel de software y que puedan dar soporte a las necesidades de la organización. Es mucho más económico adquirir uno o dos servidores para la virtualización, donde albergar n máquinas virtuales, que n servidores físicos.
Otra de las mejoras presentes con la virtualización es la escabilidad, la portabilidad y el control. Desde nuestros servidores de entornos virtualizados se puede gestionar de forma centralizada qué máquinas virtuales están activas en un momento dado así como el consumo de memoria ram y de disco de cada una de ellas. Esto nos permite tomar decisiones, y poder en un momento dado apagar una de las máquinas virtuales que no esté en uso para liberar recursos del servidor de virtualización. El despliegue de nuevos entornos virtualizados se torna también más sencillo, una vez disponemos de una máquina virtual modelo, podemos realizar réplicas para los diferentes entornos y/o proyectos, que queden expuestas a los desarrolladores una vez se han publicado en el servidor de virtualización pertinente. Respecto a la escalabilidad, las máquinas virtuales puede ser configuradas de forma dinámica con un tamaño de disco y memoria determinados, que puede variar en el tiempo, por lo que a mayores recursos necesarios para la máquina virtual, vamos a poder escalarlos mediante configuración (siempre que la máquina física disponga de los medios necesarios, claro).
Es común el uso de entornos virtualizados para dar soporte al desarrollo de aplicaciones, como por ejemplo para crear un entorno de desarrollo donde participen diferentes entidades como servidores de aplicaciones y de base de datos. También es fácil encontrar que incluso se utilice esta práctica para entornos pre-productivos.
Respecto a las pegas de estos sistemas, la principal problemática asociada es la del rendimiento, de ahí que se descarte el uso de la virtualización en muchos casos en entornos de producción, donde la velocidad de respuesta en muchos casos puede resultar crítica.
En el mercado podemos encontrar dos productos principales que ofrecen soporte respecto a la virtualización: VMWare y Virtual PC de Microsoft.
Saludos.
Miguel.
Permalink
02.06.10
Posted in AgilePoint, Arquitectura, Team Foundation Server at 12:56 pm by Miguel
A continuación un simple ejemplo de lo que podría ser un entorno de desarrollo para N desarrolladores trabajando conjuntamente en el desarrollo de un aplicativo sobre AgilePoint BPM, y con la gestión de código fuente de la aplicación mediante Team Foundation Server.
El entorno del desarrollador que podría distribuirse facilmente mediante máquinas virtuales, cuenta con todo lo necesario para la construcción. Visual Studio 2008 SP1 + Framework 3.5 SP1 para trabajar con las últimas versiones estables y consolidadas en el mercado de tecnología .NET. En el caso de estar trabajando en el desarrollo de aplicaciones web, un IIS local donde desplegar las aplicaciones web y hacer las pertinentes pruebas de desarrollo y debugs. A Visual Studio se le incorpora el plugin AgilePoint Developer para el desarrollo a medida de nuevos AgileWorks, AgileParts y AgileConnectors. Finalmente se cuenta con la disponibilidad de Microsoft Visio 2007 más el plugin AgilePoint Envision, para el desarrollo en local de las plantillas (flujos de trabajo) de AgilePoint.
En el repositorio central se almacena todo el código fuente generado por los desarrolladores mediante el uso de Team Foundation Server, que garantiza la trazabilidad del código, gestión de versiones, etc; además de poder convertirse en una herramienta de gestión y control centralizado del trabajo asociado al desarrollador. Asignación de trabajo mediante el uso de Work Items, y el control de los bugs existentes en la aplicación son algunas de sus capacidades. Al mismo tiempo, mientras el uso de Sharepoint, permite crear fácilmente portales asociados a cada uno de los proyectos en desarrollo, donde el equipo de construcción puede compartir documentación de forma centralizada y todo tipo de información de gestión o técnica asociada a cada uno de los proyectos. Debemos tener en cuenta que este entorno deberá mantener también el control de versiones asociado a las plantillas de Visio que se vayan generando mediante NVision.
El entorno de desarrollo de Agilepoint, que centraliza tanto el AgilePoint Server, la gestión web del mismo a través del Enterprise Manager, y el interfaz de servicios web que permite gestionar de forma remota y transparente el acceso a las facilidades que provee el motor de Agilepoint.
Finalmente se expone un último entorno, representativo de cada tipo de aplicación, que no hace más que definir la posible existencia de un tercer entorno de integración, necesario para el desarrollo de la aplicación, como otros servicios de comunicación u otros aplicativos existentes en el sistema sobre los que nuestra aplicación en desarrollo deba integrarse.
Un saludo.
Miguel.
Permalink
11.12.09
Posted in Arquitectura at 10:13 pm by Miguel
Y es que en más ocasiones de las que nos gustaría, en el mundo del software nos encontramos con situaciones que responden comunmente al siguiente símil.
Juan tiene un clavo y Pedro un destornillador. Juntos, quieren conseguir clavar el clavo en una tabla. Alberto, un amigo de ambos, tiene un martillo y también sabe usar el destornillador.
Antes de comenzar el trabajo Juan y Pedro se reunen; y tras descartar el pedirle el martillo a Alberto, por motivos que desconocemos, deciden clavar el clavo en la tabla con el destornillador.
Alberto, que participa como observador en la reunión, analiza la situación y transmite a Juan y Pedro sus conclusiones:
- Si intentan clavar el clavo con el destornillador, puede que al final lo claven, ahora bien, al no ser la herramienta más adecuada, van a necesitar invertir muchos recursos para conseguirlo, ya que van a enfrentarse a innumerables problemas.
- Si lo clavan, seguramente o quede el clavo torcido, o acaben rompiendo el destornillador.
- Si saben que yo tengo un martillo, y que sé clavar clavos con él, ¿por qué no me lo piden?
A partir de aquí aparecen las tres vertientes de la historia:
- Juan y Pedro le piden el martillo a Alberto. El clavo se clava y todos son felices. (Esta no suele ocurrir).
- Juan y Pedro proceden con su idea inicial. Un año más tarde de lo previsto la mitad del clavo y torcido está casi clavado en la tabla. El destornillador ya no sirve. (Esta os sonará más).
- Juan, Pedro y Alberto siguen la reunión hablando de más alternativas, de las expectativas y necesidades de cada uno. Finalmente, caen en la cuenta que a Juan no le importa quitar algo de la superficie de su clavo (donde debería golpear el martillo), ya que la final lo que quiere es clavar el clavo y eso no le afecta a su objetivo. Curiosamente el hueco que dejan en la superficie del clavo es el suficiente para que encaje el destornillador y conseguir así, sin apenas esfuerzos extra respecto al martillo, clavar el nuevo tornillo, salido tras manipular el clavo, con el destornillador. (Esta tampoco suele ocurrir).
Para los menos imaginativos o exhaustos tras una dura jornada de trabajo, una pista: la historia la ha escrito Alberto.
Un saludo.
Miguel.
Permalink
09.09.09
Posted in Arquitectura, Enterprise Library at 8:36 pm by Miguel
Y es que a la hora de acceder a una base de datos tenemos tantas opciones que muchas veces lo complicado es intentar decidir cuál de todas resulta la mejor para nuestro proyecto y/o organización.
Trabajando con .NET los dos motores de base de datos más empleados son SQL Server y Oracle, y para acceder a ellos desde una de nuestras aplicaciones podemos pasar desde utilizar los drivers propios de Microsoft para acceder a ambos gestores, con clases propuestas por el propio framework, podemos acceder a oracle a traves de los Oracle Data Access Components (ODAC) para .NET, podemos usar Datasets Tipados con sus correspondientes TableAdapter para aliviar algo el tiempo de construcción… utilizar patrones de acceso a datos como DAO+DTO… y un largo etcétera que puede pasar por soluciones caseras más o menos elaboradas, aplicaciones de otros patrones de acceso a datos como puede ser Active Record o herramientas de acceso a datos orientadas entidades como el nuevo Microsoft Entity Framework y la versión de Hibernate para .NET, NHibernate. Para más diversión, incluso pueden emplearse combinaciones de alguna de las herramientas descritas en el párrafo, intentando ajustar el esfuerzo de construcción a nuestro proyecto y, lo más complicado de todo, a nuestra planificación 
Pues ante toda esta lista interminable de herramientas, cada una con sus pros y sus contras, añado y expongo a continuación las ventajas aportadas por otra más, las Enterprise Library con su funcionalidad de acceso a datos: Data Access Application Block.
¿Qué nos aporta el Data Access Application Block?
Pues una de las principales ventajas que aporta el framework es que permite con la misma codificación atacar a diferentes gestores de bases de datos, es decir, tras preparar el acceso a datos de nuestra aplicación con enterprise library, podríamos ser capaces sin cambiar ni una línea de código (no os toméis esto al pie de la letra, que seguro que algo habrá que cambiar aunque sea mínimo), de pasar de atacar a un SQL Server a un Oracle. Esta puede ser una gran ventaja si estáis preparando un producto al que dependiendo del cliente al que se lo vendáis tengáis que garantizar el soporte de ambos gestores, porque por ejemplo alguno de vuestros clientes esté casado con Oracle y otro con SQL Server. Con un sólo desarrollo de vuestra capa de acceso a datos cubriréis toda la casuística (menos los procedimientos almacenados, claro, que os va a tocar picarlos dos veces ).
Otras ventajas a tener en cuenta son la facilidad de configuración. Una vez instaladas las enterprise library disponemos de una pequeña aplicación que apuntándola al Web.Config o App.Config de nuestro aplicativo permite editar las propiedades de conexión de manera visual. Pudiendo configurar el proveedor de la conexión, tipos de autenticación y más parámetros propios de una conexión a datos de forma muy cómoda y sencilla.
Una vez configurada la conexión, con una línea como la siguiente conectamos con el gestor, independientemente de cuál sea (DataBase y DataBaseFactory son clases del Data Access Application Block).
Database nuestraDB = DatabaseFactory.CreateDatabase(“nombreConnectionString”);
Para hacer una consulta que retorne un conjunto de registros a través de un procedimiento almacenado:
DataReader ejemploDR = nuestraDB.ExecuteReader(CommandType.StoredProcedure, “spu_get_allitems”);
Y para recorrer el datareader, pues como siempre, utilizando el método Read y luego en el registro sobre el que trabajamos obteniendo el dato a través del identificador de la columna.
Como véis es rápido y sencillo (no tanto para los que os toque trabajar contra Oracle, ya que os vais a necesitar conocer algún truquillo extra), y os ayuda a mantener una total independencia con el gestor de base de datos.
Bajo mi humilde opinión, Data Access Application Block podría ser un buen candidato a herramienta de acceso a datos corporativo en cuanto al desarrollo de soluciones .NET.
Saludos.
Miguel.
DAB.Database dbTampico =
DAB.DatabaseFactory.CreateDatabase(“cnTampico”);
Permalink
06.09.09
Posted in .NET, Arquitectura, Web at 5:56 pm by Miguel
Una de las herramientas más comunes a la hora de trabajar con aplicaciones web son las variables de sesión.
Dejando de lado en este capítulo las recomendaciones de arquitectura en el uso de las sesiones, simplemente plantear una solución a uno de los típicos problemas que se encuentran los arquitectos de software a la hora de definir el uso de sesiones, que son las limitaciones al uso relacionadas a entornos donde se cuente con una infraestructura que ofrezca alta disponibilidad cuando estamos trabajando con variables de sesión almacenadas en la memoria del servidor.
Para solucionar este problema, existen productos disponibles en el mercado, que lo que hacen es mantener también balanceado el contenido de la sesión de todos los servidores existentes en una granja, por lo que, aunque un usuario a medida que va lanzando peticiones, el balanceador lo vaya dirigiendo a servidores diferentes, podrá seguir trabajando con la información de sesión que haya generado, en memoria, en un servidor diferente.
Os dejo el link a uno de los productos que solventa este problema en entornos .NET: NCache
http://www.alachisoft.com/ncache/
Saludos.
Miguel.
Permalink
06.03.09
Posted in Arquitectura, Colas de Mensajería, Web at 7:34 pm by Miguel
Estrenando en el blog el mundo de las Colas de Mensajería, y la categoría recién inaugurada a tal efecto, hoy vamos a hablar cómo se está explotando en la actualidad las capacidades que ofrecen estos sistemas en entornos web.
A priori, y conociéndo únicamente las características básicas de funcionamiento de las aplicaciones cliente-servidor web y los sistemas de colas de mensajería, resulta de extrañar que pueda sacarse algún tipo de partido combinándolas, ya que:
- La relación entre un cliente web y el servidor es síncrona y uni-direccional. El cliente solicita la comunicación con el servidor, quedando a la espera de respuesta antes de poder seguir el hilo de ejecución, de forma, insisto, totalmente síncrona.
- En cambio un sistema de gestión de colas es en esencia asíncrono, ya que, a grandes rasgos, consiste en un punto de entrada que va almacenando peticiones en un determinado órden, y que garantiza que las peticiones van a llegar al destino, pero por defecto no garantiza cuándo. En cuanto la petición ha sido procesada, la respuesta se asocia a un punto de salida, el cual la aplicación llamante debe consultar para conocer el resultado del procesamiento.
Entonces, si el trabajo en web es síncrono, y los sistemas de colas de mensajería asíncronos, ¿como podemos obtener algún tipo de beneficio? Paso a enumerar escenarios:
- Se debe realizar un cálculo que requiere de tiempos no manejables en entornos web de manera síncrona (más de 1 minuto se podría considerar como inmanejable).
- La petición que se recibe en el servidor sólo es ejecutable en algunas ventanas de tiempo.
- No es necesaria la notificación de ejecución completa al usuario una vez lanzado un proceso, por lo que podemos gestionar internamente cuándo lanzararemos el proceso demandando para optimizar así el consumo de cpu y memoria.
Se pueden encontrar muchos ejemplos de estos usos por ejemplo en redes sociales como Facebook, donde en muchas ocasiones se proponen envíos masivos de notificaciones, invitaciones y noticias a un grupo muy grande de usuarios. Una vez realizada la petición, esta es encolada y ejecutada a posteriori.El usuario no tiene necesidad de conocer a ciencia cierta que la petición se ha ejecutado en el momento, se conformo en saber que los avisos, llegarán. Lo mismo ocurre con otros sistemas muy habituales como son los envíos de SMS a través de teléfono móvil.
La ventaja y moraleja del artículo respecto a todo esto, es que el uso sistemas basados en colas de mensajería ayudan a maximizar la experiencia de usuario en entornos web, ya que tras una petición que podría resultar en una larga espera síncrona hasta que el servidor haya terminado de ejecutar la petición, esta termina al momento (desde el punto de vista del usuario), y el usuario puede seguir utilizando la aplicación sin problemas. Mientras tanto, por detrás, el gestor de mensajes ha encolado la petición, la cual, en su momento, será ejecutada.
Si vuestro escenario es similar al aquí planteado, emplear una solución basada en sistemas de colas de mensajería, podría ser una buena solución de arquitectura.
Saludos.
Miguel.
Permalink
06.02.09
Posted in .NET, Arquitectura, Web at 6:47 pm by Miguel
A continuación paso a enumera una serie de consideraciones a tener en cuenta y que os pueden ser útiles a la hora de tomar ciertas decisiones de arquitectura al respecto del uso de variables de sesión. Como veréis algunas de ellas tienen que ver con entornos .NET, ya que es la plataforma con la que suelo trabajar, pero la mayoría son aplicables a otros entornos tecnológicos no Microsoft.
Sesión en Memoria vs Sesión en Sistemas Persistidos (Base de Datos o Servicios del Sistema Operativo)
La forma más eficiente de trabajar con sesiones es manteniendo su contenido en memoria. En el caso de estar trabajando con una granja de servidores, pueden utilizarse soluciones existentes en el mercado como es NCache, para balancear el contenido de las sesiones en memoria entre todos los servidores de la granja.
En caso de no poder barajar esta alternativa existen soluciones que permiten almacenar el contenido de la sesión sobre sistemas persistidos. Esta solución es más lenta, pero permite compartir la información de sesión sobre diferentes servidores, además de garantizar que aunque se reinicie el servidor de aplicaciones, la información de sesión va a permanecer disponible cuando la aplicación vuelva a arrancarse.
Cantidad de Memoria en Uso
El uso de sesión afecta directamente al consumo de memoria del servidor que está ejecutando las llamadas del cliente, por lo que deberá almacenarse en sesión únicamente la información que se considera imprescindible y que, se recomienda, esté relacionada con alguna de las siguientes características:
- Información básica relacionada con la autenticación o la seguridad del usuario y que es necesario comprobar en las llamadas o peticiones que realiza el usuario contra la aplicación.
- Otro tipo de información funcional asociada al usuario, que va a permanecer estática a lo largo de toda la vida de la sesión y que es requerida de forma constante en las peticiones que realiza el usuario a la aplicación. El objetivo de este punto sería minimizar el número de llamadas a base de datos.
Tipos de Objetos en Memoria
Los objetos almacenados en la sesión deben ser en todo caso de poco peso, minimizando así la cantidad de información almacenada por sesión por cada objeto. Se recomienda el uso de objetos de negocio que incluyan tipos de datos básicos. No se recomienda el almacenamiento de objetos propietarios de .NET del tipo Dataset ó DataTable debido al tamaño asociado a los mismos.
Manejando Información Sensible
Si el contenido almacenado en la sesión contiene información sensible, como podrían ser contraseñas o información personal del usuario activo, ésta deberá permanecer encriptada durante todo el ciclo de vida de la sesión.
Usando Sesión a modo de Caché
No debe emplearse la sesión para almacenar catálogos de datos comunes de la aplicación, como podrían ser listados de países, regiones, provincias, etc, ya que éste no es el objetivo de este tipo de objeto. Para estos casos se deberá recurrir a un objeto de tipo caché.
Usando Sesión a modo de Viewstate (específico .NET)
No se recomienda emplear la sesión para almacenar información que será necesaria explotar entre llamadas a la misma página, ya que para ello existe un objeto preparado específicamente para resolver esta problemática como es el Viewstate de ASP.NET.
Usando Sesión a modo de POST y GET
No debe emplearse la sesión para transportar información entre páginas de la misma aplicación, ya que para ello se deberá recurrir a los objetos POST y GET.
Liberando Información de Sesión
Siempre y cuando se detecte que la información almacenada en sesión deje de ser necesaria para la sesión de usuario actual, se debe solicitar la liberación de la memoria asociada al servidor.
Saludos.
Miguel.
Permalink
06.01.09
Posted in Arquitectura, Patrones at 11:28 pm by Miguel
En la sección de patrones de diseño inauguramos los patrones de Ajax, con la descripción del patrón: Refresco Periódico.
El patrón viene a describir la solución a un problema común y que parte de una de las principales limitaciones de la soluciones web, la uni-direccionalidad de la relación cliente-servidor. La parte cliente es la que siempre toma la iniciativa ante cualquier transacción, por lo que si en las situaciones en las que queremos mostrar un aviso de cuándo un proceso de cálculo complejo que se ha lanzado de forma asíncrona ha terminado, o cuando por ejemplo a los usuarios autenticados en nuestra aplicación queremos mostrarles un aviso de que se ha recibido stock de un determinado producto, no tenemos más remedio que utilizar diferente estrategias, siempre por parte del cliente, para “engañar al usuario”.
Una de las soluciones a este típico problema es el uso del Patrón del Refresco Periódico, que a grandes rasgos consiste en realizar llamadas periódicas a través de ajax al servidor, para ir solicitando el refresco del estado de la información que necesitamos consultar. Como al utilizar ajax la página no se refresca de forma completa, la experiencia de usuario da como resultado algo bastante similar a lo que puede aportar una aplicación de escritorio.
Más información en http://ajaxpatterns.org/Periodic_Refresh
Saludos.
Miguel.
Permalink
11.28.08
Posted in AgilePoint, Arquitectura, BPM, Servicios Web, WCF, Web at 12:53 pm by Miguel
En un artículo anterior hablábamos de la autenticación con AgilePoint y la surrogación. Echaba en falta algún gráfico que dejara algo más clara la forma de trabajar, así que lo adjunto en esta segunda parte.
Esquema Surrogate
Como véis, se aprecian las tres combinaciones de las que se habla en la primera parte.
- Opción A: Usuario a través de un navegador web, el servidor web tiene que impersonar al usuario llamante.
- Opción B: Usuario a través de aplicación de escritorio que trabaja contra una capa de servicios, el servidor de negocio tiene que impersonar al usuario llamante.
- Opción C: Usuario a trvés de aplicación de escritorio que trabaja directamente con servicios de AgilePont, no hace falta impersonación, el propio usuario pertenece al dominio y se autentica directamente con sus credenciales de red.
Pocos artículos últimamente. Mucho trabajo.
Saludos!
Miguel.
Permalink
« Previous entries Next Page » Next Page »
