SubSonic - ActionPack

Una de las ventajas de los lenguajes dinámicos es que los ORMs o pseudo-ORMs que se utilizan pueden generarse totalmente con la información de la base de datos. El más conocido ejemplo de esto hoy en día es ActiveRecord que es una implementación del patrón ActiveRecord en Ruby, y es el más famoso por ser utilizado por Ruby on Rails(ROR). Como los que leen mi blog saben soy un seguidor de Python más que Ruby por lo que mi implementación favortia de este tipo de ORMS es SQLObject, y si quieren un framework MVC prefiero TurboGears, pero bueno no voy a desviarme del tema.

Los que me conocen saben también que no soy amigo de los ORM entonces porque lo que se preguntarán porque lo menciono en el mundo dinámico. Bueno porque en el mundo dinámico el costo de creación del objeto en sí hace que el costo del ORM sea despreciable. Además que todo el manejo de SQLObject me parece muy coherente y segundo porque todo el concepto de mapeo puede hacer que todo el proceso sea muy complicado. Pero si se pudiera tener algo efecitvo y ligero no estaría de más.

En el mundo CLR he visto varios intentos de hacer cosas similares (ActiveRecord de CastleProject por ejemplo) casi siempre asociado a proyectos de creación de frameworks MVC al estilo de ROR (MonoRail). Sin embargo en estos proyectos he encontrado el problema común de la creación de los objetos, dado que el CLR es fuertemente tipado las clases deben ser conocidas por el compilador y no pueden ser modificadas posteriormente lo que limita mucho la creación automática.

Muchos proyectos han optado por la generación de código fuente para evitarse el problema de la generación del CIL. Esta opción es muy utilizada (CodeSmith es el ejemplo del que más he oido hablar) y creo que da buenos resultados, sin embargo estas soluciones requieren que cuando cambias o agregas elementos a tu base de datos debas regenerar la solución y recompilarla, dado que muchas veces agregas elementos sin modificar lo anterior no es lo más lógico reconstruir todo al menos no desde el origen.

CastleProject trato de usar su conocimiento de generación de CIL para facilitarlo así que basandose en NHibernate obtuvieron algo interesante, pero aún así se debe declarar la clase base y su comportamiento con lo cual no ganaron mucho.

Revisando algunas cosas me encontré con Commerce Starter Kit una aplicación para la creación de sitios de comercio electrónico, el proyecto en si es interesante, pero lo que más me llamó la atención fue su enfoque MVC basado en SubSonic y ActionPack ¿porque me llamo la atención? porque no es necesario generar el código intermedio convirtiendose en una verdadera DAL sin código.

Al principio me pareció demasiado vudú por el hecho ya mencionado de ser el CLR tipado así que me dedique a ver la solución, conforme revise SubSonic (la parte de acceso a datos de ActionPack) entendí su solución y me encantó.

Lo que hace SubSonic es crear un proveedor de Build para ASP.Net lo que le permite que generen el código en demanda y sin necesidad de crear los archivos intermedios, una solución sencilla y altamente efectiva.

Este simple cambio de ubicación hace que la solución sea mucho más fácil de utilizar que otros modelos que haya visto y genera un escenario muy limpio ¿Por qué? porque las clases se generán dinámicamente y sin necesidad de crear archivos adicional y sin importar el lenguaje en el que programes.Obviamente un nivel de abstracción no es lo suficientemente bueno si no puedes modificarlo por lo que, si así lo quieres, puedes generar los archivos intermedios y/o modificar las plantillas DOM para la generación de los mismos.

Si uno lo piensa la tecnología utilizada es la misma que en los otros casos pero el enfoque y modo de combinación es lo que hace que SubSonic sea una solución muy simple y práctica para el uso en frameworks Web y estoy pensando seriamente en su validez en otros escenarios.

A veces la innovación no esta en la tecnología sino en la forma de uso de la misma. Ya les contare de mis pruebas con SubSonic y en un siguiente post hablaré de la parte de scaffolding de Action Pack.

Nota: Obviamente piensen que para usarlo tienen que tener su modelo de datos completo después de todo Active Record parte de la base de datos.

LOB Adapter SDK for WCF

La semana pasada estuve en un conjunto de conferencias de distintos temas y fuera de un tema de HPC que estoy analizando lo que más me llamo la atención, y que creo que es un salto muy interesante en el concepto de integración de aplicaciones, es el LOB Adapter SDK for WCF (Kit de desarrollo de adaptadores para aplicaciones de negocio para WCF)

Este SDK, que esta en Beta junto con BizTalk R2, es una extensión a WCF para construir conectores con aplicaciones de negocio. En primera instancia debo decir que me pareció muy raro que hubiera algo de este estilo pues con lo extensible que es WCF el construir un nuevo transporte y/o encoder es bastante simple con lo que se podría crear bindings para cualquier aplicación.

Sin embargo hay un par de aspectos que son importantes para los conectores que son necesarios implementar y que los sabios pudieron explicar a este moral.

• Metadata: Es necesario buscar un mecanismo para el intercambio y acceso a la metadata de la aplicación de negocios a la que se quiere acceder. Esto no es un tema simple porque a diferencia de un servicio o servicios específicos en cuyo caso se puede intercambiar toda la información relacionada con esquemas, contratos y políticas de comunicación (WS-MetadataExchange es el protocolo diseñado para este intercambio) una aplicación puede exponer una gran variedad de funciones y endpoints de distinta indoles y/o categoría de manera no organizada en servicios. Estas funciones, adempás, pueden o no estar disponibles y variar de acuerdo a la instalación o configuración del sistema.
  El mejor ejemplo de este tipo de comportamiento lo dan SAP, JDE, PeopleSOft, Siebel cuyos sistemas pueden tener dependiendo de la instalación y configuración conjuntos muy distintos de funciones expuestas para el acceso por parte de los usuarios. .
• Creación del proxy: Un problema derivado del anterior esta en la creación del cliente dado que la metadata no es necesariamente expuesta en términos manejables por MEX (WS-MetadataExchange) svcutil no es una herramienta que se pueda utilizar para la creación del cliente.

Anteriormente los distintos adaptadores de LOB se generaban los desarrolladores del mismo eran los encargados de crear herramientas para realizar las dos tareas anteriores por ejemplo: el SAP.Net conector de SAP tenia herramientas para la creación los proxies a ser utilizados en .Net mientras que el SAP Adapter para BizTalk tenía otra herramienta para la creación de los esquemas a ser utilizados en los endpoints y el intento de SAP data source para SSIS tenía su propio desarrollo para solucionar estos problemas.

Obviamente con el crecimiento de necesidades de integración en las distintas aplicaciones esto es una necesidad cada vez más común. Por ejemplo solo en productos de microsoft los siguientes productos necesitan conectores a sistemas de este tipo: BizTalk, SharePoint, SSIS, SSRS (Reporting), MILM (Identity Lifecycle Manager), potencialmente MOM y seguro algún otro que se me pasa de lado.

Por todo esto es que el equipo de integración de Microsoft empezó a trabajar en un framework para la creación de adaptador para aplicaciones de negocio que cumpla con los requerimientos base de todas las aplicaciones permitiendo que la conexión punto a punto pueda ser resulta una sola vez y reutilizada por todos.

El framework obviamente se basa en la plataforma de servicios y comunicación de Microsoft WCF y provee una arquitectura que ya explicaré en algún otro post. El framework provee un conjunto de elementos reutilizables que asegura que el desarrollador de un conector tenga que limitarse a lo estrictamente necesario, que es:

• Emision, consulta y busqueda de Metadata: La diferencia en este punto es que el desarrollador expondrá unas cuantas interfaces comunes y que manejan las descripciones de manera abstracta. El framework brindará todo el mapeo de esos esquemas con WSDL, XSD, MEX, etc. asegurando que una aplicación que necesite de adaptadores no deba conocer a los mismos directamente y pueda hacer uso de las mismas.
• Creación de conexiones: Es bastante claro que el adaptador es el que conoce como conectarse con el servidor por lo que la creación de las conexiones es netamente su responsabilidad.
• Envio y recepción de mensajes: El día que nos podamos librar de esto estaremos listo para dar el siguiente y buscar otro trabajo :)

En otro post entraré en más detalle de la plataforma pero debo decir que lo que vi hasta ahora es muy bueno y vale la pena seguirle el paso

Marc Fleury deja RedHat

Los que me conocen y con los que hemos hablado de Java Application Servers saben que a pesar de que no soy un fanático de Java para mi la mejor solución de ese lado es JBoss. Esta opinión se basa en muchas cosas: su enfoque respecto al stack de JEE, su visión de donde van los application servers en general y su visión de un Open Source Profesional - aún hoy considero que el paper de Marc Fleury en el tema, fundador de JBoss, es muy interesante como modelo de negocios y algo a considerar.

Hace un tiempo RedHat compro JBoss y fue todo un hito en el mundo Open Source, Marc estaba muy emocionado por tener todo el respaldo que le daba Red Hat para seguir trabajando en su modelo de Open Source profesional y fortalecer el áea de Investigación y desarrollo.

Bueno, con todo eso dicho voy al tema del post. Habitualmente sigo el curso de JEMS (Java Enterprise Middleare Suite) y hace ya unos dos meses que se corrían muchos rumores de la "infelicidad" de Marc Fleury en Red Hat, principalmente porque sus expectativas de lo que podría hacer y quería hacer no se estaban realizando. Creo que el pobre Mac no contaba con que al final del día Red Hat es una corporación y no precisamente alineada con su modelo Open Source Profesional.

Todo esto se fortalece cuando hace un mes casi Marc toma "vacaciones indefinidas" respaldado por el nacimiento de su último hijo, este aviso disparó muchos más rumores y casi aseveraciones de la inminente salida de Fleury la historia siguió por semanas pero fue recien el día de hoy se oficializó que Marc no vuelve a Red Hat. Los comentarios que leí dicen que por un tiempo se dedicará a la enseñanza y a pasar tiempo con su familia, esa es una gran noticia para Marc pero algo para pensar para los que defienden el modelo de Red Hat como un modelo de Open Source comercial.

Es bien sabido que Red Hat es la oveja negra de todos aquellos que se consideran seguidores del modelo Open Source sin embargo creo que esto es la prueba definitiva de la divergencia entre el proveedor más importante de Linux para empresas y la corriente Open Source.

Sinceramente espero que no sea lo último que escuchemos de Marc insisto que hasta la fecha su visión en relación a Open Source es la única que me ha parecido sostenible y coherente. Eso sí no puedo negar que espero que la próxima vez que se sepa de él sea en el mundo de CLI y no de JVM ;)