10.26.08
Posted in .NET, Framework, Programación at 12:44 pm by Miguel
Es curioso el siguiente nuevo mecanismo que aparece en el .NET Framework 3.5,
namespace MetodosExtension
{
public static class MisExtensiones
{
public static bool ContieneLaZ(this String str)
{
//Código que a partir de un string retorna verdadero
//si éste contiene la letra ‘Z’
}
}
}
Que luego te deja hacer cosas como esta;
string variable = “escuché un zumbido”;
if (variable.ContieneLaZ())
{
}
A esta nueva facilidad que incluye el entorno de desarrollo se le llaman extensiones. Como podréis apreciar lo que se ha hecho es definir en una clase separada un nuevo método asociado a un objeto (String) que el propio framework de .NET trae consigo. La magia para conseguir esto último reside en la forma en la que se define el parámetro del método “ContieneLaZ”, que como véis utiliza el identificador “this” previo a la definición de la variable y el tipo.
La principal gracia de todo esto es la capacidad de poder dotar de más potencia a clases ya definidas sin necesidad de utilizar tipos derivados y sin modificar el tipo original.
Apuntar además que las extensiones se mantienen también cuando heredamos la clase original sobre la que se ha hecho la extensión. Por ejemplo, si extendemos la clase “Coche” con nuevas operaciones, y luego creamos una clase “CocheVolador”, esta última, también podrá contar con las extensiones definidas en su clase padre.
Saludos.
Miguel.
Permalink
10.17.08
Posted in .NET, Arquitectura, Herramientas, Programación, Software, WCF at 8:22 pm by Miguel
Recientemente he tenido la oportunidad de participar en una presentación de Solid RAD, la herramienta para el desarrollo rápido de aplicaciones, ofrecida bajo el sello y garantía de calidad del equipo de Solid Quality Mentors
Jesús López y Daniel Seara (con el cual he tenido nuevamente el placer de coincidir) han sido los dos mentores de Solid que realizaron la presentación de forma conjunta.
A partir de la propia arquitectura y orientación de Solid RAD, la cual podréis conocer consultando el video provisto en el siguiente enlace mms://solidq.com/SolidRad (copiar el link y ejecutar pegando en la barra de dirección de Internet Explorer), destacar la inmensa oportunidad que supone compartir durante parte de una mañana, y de forma directa y personalizada, de los conocimientos y opiniones de los dos mentores. Lo que ha dado una pequeña “discusión” sobre el uso de las transacciones es algo que me gustaría exponer en un próximo artículo. A mi la visión me ha parecido genial.
Destacar entre otras cosas de Solid RAD, otras ideas fantásticas, como las de partir de un modelo de objetos de negocio para exponer el conocimiento a otras capas, pero sin orientar el modelo de objetos directamente a las entidades de datos, tal como haría un ORM, si no a las vistas definidas sobre dichas entidades de datos. Es una idea simplemente genial combiándola al mismo tiempo con el generador de código de Solid RAD, que automatiza la generación de las entidades de transporte de datos a partir de las propiedades de cada una de las vistas sobre la que es accedida.
Saludos.
Miguel.
Permalink
10.08.08
Posted in .NET, AgilePoint, BPM, Programación, Servicios Web, Web at 9:34 pm by Miguel
Una de las principales capacidades que ofrece AgilePoint como producto, es la orientación a servicios que han dado a la solución de software. Para ello, en la versión 4.0 de la herramienta ofrecen en concreto dos servicios que agrupan todos los métodos que permiten acceder a la funcionalidad del motor.
workflow.asmx
Servicio que encapsula todos los métodos asociados a la manipulación de los flujos (incluyendo por ejemplo servicios para instanciar plantillas, obtener información de un proceso, establecer el valor de una de las propiedades de un proceso…).
admin.asmx
Servicio que encapsula todos los métodos asociados a la administración del propio motor (incluyendo por ejemplo servicios específicos para la creación de usuarios, permisos, roles…).
A priori, con estas dos piezas, y desde cualquier tipo de tecnología cliente, podríamos manipular el BPM desde una aplicación cliente creada por nosotros mismos.
La pieza que aquí nos falta es conocer cómo se protege AgilePoint para que no todos los usuarios que tengan acceso a dichos asmx puedan utilizarlos para acceder al motor y manipularlo a su gusto. Como comprenderéis, si no existiera dicha autenticación estaríamos hablado de un fallo de seguridad como la copa de un pino.
El requerimiento indispensable para poder acceder a los servicios, es que el mismo objeto que está realizando la conexión al servicio cuente con las credenciales de red del usuario que está haciendo la llamada. Esto ya en principio garantiza que la persona que está llamando al servicio está autenticada en el dominio, que quieras que no, supone una primera barrera de seguridad. Pero esto, no es suficiente, ya que necesitaremos que el usuario que esté haciendo la llamada también esté dado de alta en la propia base de datos de usuarios de Agilepoint. Como curiosidad, remarcar que la propia herramienta de gestión de usuarios de AgilePoint provee de facilidades para sincronizarse con el directorio activo e importar la información de los usuarios de dicho directorio a la base de datos de usuario de AgilePoint.
Resumiendo, si disponemos de nuestras credenciales de red validadas, se las pasamos a AgilePoint y nuestro usuario está también incluido en el repositorio de usuarios de AgilePoint, olé, ya podemos usar los servicios sin problemas.
Pongamos por ejemplo que estamos trabajando con una aplicación de escritorio que referencia los servicios web de AgilePoint directamente. Siguiendo este procedimiento, conseguiremos autenticarnos sin problema.
La casuística complicada viene cuando por ejemplo trabajando en web, o en el caso de que no conectemos directamente con nuestra aplicación al servicio, si no que tengamos otra aplicación que haga la conexión en nuestro nombre. Estaríamos hablando de una típica aplicación web, donde el usuario que la está ejecutando es del del pool del servidor de aplicaciones y no la persona que ha abierto el navegador en su casa… o en el caso de que nuestra aplicación de servicios no ataque directamente a los servicios de AgilePoint si no que llame a una capa de negocio con orientación a servicios que sea la que se encargue después de llamar a Agilepoint. En ambos casos tenemos “algo”por enmedio que tiene sus propias credenciales que no son precisamente las nuestras.
Ante este problema tenemos una primera solución para lograr la autenticación, nos creamos un usuario para ese “algo” intermedio en nuestro directorio activo, lo damos de alta también en la base de datos de Agilepoint, y ala, cuando llamemos al “algo” este se podrá autenticar y hacer el trabajo sin problemas. Esto funciona, pero tiene un problema de base, que todos los usuarios trabajarán contra el BPM usando el mismo usuario, y esto va en contra del funcionamiento basado en flujos.
Como hemos tratado ya en otros artículos, uno de los componentes principales de un motor de flujo es el responsable de cada una de las tareas definidas en el flujo de trabajo. Parte de la gracia de este sistema de trabajo es que la persona que conoce el negocio define las responsabilidades de cada uno de los pasos a seguir, y a partir de esta responsabilidad, los usuarios asignados tendrán constancia de que tienen que realizar cada una de las tareas. Imaginaos entonces que siguiendo un flujo determinado se asigna la responsabilidad de las tareas generadas a una serie de usuarios. ¿Cómo voy a conseguir entonces preguntarle al motor de flujo que me de las tareas de dicho usuario específico si siempre estoy haciendo login a través de un usuario intermedio común a todos? En este caso todos seríamos el mismo usuario y recibiríamos siempre las mismas tareas.
Después de toda la puesta en situación inicial llegamos entonces al punto clave y objetivo del artículo, el Surrogate. Mediante la “surrogación” (no creo que esté este palabro en ningún diccionario) conseguimos decir en la autenticación que el usuario intermedio común a todos hable en nombre de otro. Es decir, nos autenticamos igual, pero en un momento dado dicho usuario le dice a AgilePoint: “Oye tío, yo soy el que me autentico siempre, estas son mis credenciales y seguro que además me tienes en tu base de datos, y, a partir de ahora mismo todas las operaciones que voy a mandarte las voy a hacer en nombre de Pepe, por lo tanto, cuando te pida que me des todas las tareas en estado ofrecido me estoy refiriendo a las de Pepe, y cuando te diga que proceses una tarea lo vas a hacer también en nombre de Pepe”.
Claro está, “Pepe” va a tener que estar dado de alta en el repositorio de usuario de AgilePoint, o si no por mucho que le diga “el de siempre” que va a hablar en nombre de “Pepe”, AgilePoint va a responder: “no sé de quién me estás hablando”.
A partir de aquí, para ver a nivel de código cómo funciona esto, os dejo un link de la página de Ascentn donde podéis ver el ejemplo:
Ejemplo KB-Ascentn
Para acabar, y como podréis ver en el link que os acabo de dejar, no todos los usuario disponibles en el repositorio de usuarios de AgilePoint tienen la capacidad de hablar en el nombre de otros. Para disponer de dicha capacidad, se debe dar de alta el usuario como “Impersonator” a través de la herramienta de configuración del servidor de AgilePoint.
Espero haberme explicado con suficiente claridad, no es precisamente fácil intentar trasladar el uso del Surrogate.
Saludos.
Miguel.
Permalink
10.02.08
Posted in Arquitectura, Bases de Datos, Metodologías, Software at 8:09 pm by Miguel
[Actualizado a 05/10/2008]
A continuación os planteo un típico problema de modelo entidad-relación en base de datos, en el que se debe modelar una situación bastante común en un desarrollo de software. Os pediría que intentarais resolver el problema sin ver antes las tres soluciones que marco al “ejercicio” en la parte final del post, y comprobar así finalmente cuál ha sido el tipo de solución más habitual. Os agradecería además que razonarais la respuesta. En el caso de que vuestra solución no se ajuste a ninguna de las tres descritas, por favor, enviadme un diagrama a info@miguelmatas.es para que pueda adjuntarla al artículo. Sería estupendo además que en el razonamiento de vuestra solución no se limitara a las razones estríctamente del modelo y la base de datos, si no que estuviera acompañada de algún razonamiento relacionado con arquitectura de software, orientación al negocio, eficiencia a nivel de datos, protección del dato, etc. En el caso de que no queráis “perder” tanto tiempo, me doy por satisfecho si contestáis al post indicando si vuestra solución se acerca a una de las tres primeras o ha sido otra 
Gracias!
Enunciado:
Una conocida empresa de Rent a Car quiere informatizar su sistema de gestión de vehículos. En esencia, dicha empresa alquila de forma temporal los coches de los que dispone, y, en un primer proceso de ingeniería necesita contar con una descripción técnica de cómo se almacenarían el repositorio de los diferentes coches con los que cuenta en cartera.
La empresa cuenta con diferentes tipos de coches, son realmente los tipos de coches que maneja lo que la diferencia de los Rent a Car al uso, ya que los usuarios tienen la oportunidad de alquilar coches anfibios, coches voladores y coches oficiales blindados. Estos tres tipos de coche tienen algunas características en común que se desean conocer, como son la matrícula, el número de puertas y la marca. Además, de forma específica se necesita conocer el máximo de nudos a la hora a la que puede navegar un coche anfibio, los milímetros de blindaje y el tipo de blindaje de un coche oficial blindado, y la autonomía de horas de vuelo con las que cuenta un coche volador.
Posibles soluciones de modelado entidad-relación:
Os pediría por favor que no consultarais las soluciones hasta que hayáis desarrollado vuestra propia solución, para así no interferir en el resultado.
Solución 1
Solución 2
Solución 3
Solución 4 [nuevo 05/10/2008]
Saludos y gracias
Miguel.
Permalink