Hace algunos años fui contratado para integrar un CRM y Salesforce (se llamaba así en ese entonces). Para realizar la integración usé C# y el Enterprise API de Salesforce para llevar los datos del CRM al repositorio en línea de Salesforce. Un ejercicio harto interesante. También leí algo acerca de la PartnerApi y de ahí surgió la inquietud de utilizarla.
El objetivo que se me presentó en mi mente fue crear una biblioteca que simplificara el uso de esta PartnerApi y pues después de mmuuuucho tiempo aquí está.
Acabo de publicar el código, licenciado bajo LGPL, para que todo mundo lo revise, lo use y ojalá y contribuya a este proyecto.
Cualquier comentario, sugerencia o pregunta son bienvenidas.
Finito.
martes, 26 de junio de 2007
Enterprise Architecture
Hola que tal!!!
Hace unos meses escuche el termino Arquitectura Empresarial y como buen técnico de entrada pensé que hablaba de arquitectura de software, de componentes en fin todo relacionado con tecnología y no es que estuviera mal, pero en una empresa no todo es tecnología... el buen Gus siempre hacia énfasis en ver todas las perspectivas que encontramos dentro de una organización.... lo que le da vida....
Si quisiera hablar de Arquitectura empresarial en una frase la dejaría como sigue: "Se refiere a el conjunto de PROCESOS DE NEGOCIO de una organización, como estos procesos son implementados con TECNOLOGIA y como son llevados a cabo por PERSONAS", quizá gus, o muchos de ustedes complementaran esta frase... , como pueden ver este tridente PERSONAS-PROCESOS-TECNOLOGIA es el alma de una empresa...
Para la empresa lo mas importante son sus PROCESOS de negocio... todos y cada uno de ellos desde procesos bancarios, procesos de pagos, procesos de nomina... en fin los que se les ocurran.... por otra parte están las PERSONAS el lado humano el lado que echa a andar los procesos, cumpliendo tareas especificas que permitirán lograr los objetivos de la organización.... y soportando ambas cosas esta
Un Framework muy interesante es el llamado Framework de Zachman para Arquitectura empresarial, el cual define diferentes perspectivas como Que (datos), Como (funciones), Donde (ubicación), Quien (personas), Cuando (tiempo) y Porque(Motivación), a su vez estas perspectivas pueden cruzarse con el Alcance (objetivos estratégicos de la organización), Modelo Empresarial (Modelado de procesos de negocio), el Modelo del Sistema(Modelos Lógicos), Modelo Tecnológico (Definición y desarrollo de la solución), Componentes y los Sistemas en operación (Empresa Funcionando)....
Si algún día necesitan realizar un diagnostico de
Ahora veamos la famosa pregunta ¿como alinear TI a los objetivos de la organización?.. Quizá la respuesta la encontremos en la arquitectura empresarial....
Saludos!!!
Tuzo
jueves, 14 de junio de 2007
The role of ESBs
Hola que tal
Cuando hablamos de implementar una solucion ESB en alguna organizacion, nos viene a la mente lo costoso que implicara hacer este tipo de proyectos..... en el mercado existen una serie de productos comerciales que ofrecen todas las capacidades que nos entrega un ESB, por mencionar algunos Sonic ESB, Aqualogic Service Bus... ya hasta microsoft ofrece con BizTalk una solucion ESB (segun je je.. sorry)... y el punto aqui es que las licencias anuales se facturan en millones de dolares.... me pregunto... ¿las soluciones ESB estan solo al alcance de grandes companias en el mundo? .. lo que no hemos hecho muchos de nosostros es voltear al mundo open source y ver que tenemos alternativas realmente interesantes como Mule ESB, Celtix, Service Mix, etc.. que bien implementadas se puede obtener un resultado realmente interesante comparado con las soluciones comerciales...
Mas preguntas....¿Como poder justificar una compra de una herramienta que cuesta millones de pesos? ¿Como justificar realmente el valor del modelo SOA? ..... para los que estan trabajando en dependencias gubernamentales (y con esto del decreto de austeridad) ..¿ como se puede de verdad reducir costos anuales de uso de licencias de software?...... quiza estas respuestas estan en las soluciones opensource ... ¿sera?
Bueno pues aqui les dejo una interesante entrevista en la que habla Ross Mason fundador de Mule ESB, acerca del rol de los ESBs...
Por una integracion mejor, hasta la vista!!
Tuzo... Campeon
Cuando hablamos de implementar una solucion ESB en alguna organizacion, nos viene a la mente lo costoso que implicara hacer este tipo de proyectos..... en el mercado existen una serie de productos comerciales que ofrecen todas las capacidades que nos entrega un ESB, por mencionar algunos Sonic ESB, Aqualogic Service Bus... ya hasta microsoft ofrece con BizTalk una solucion ESB (segun je je.. sorry)... y el punto aqui es que las licencias anuales se facturan en millones de dolares.... me pregunto... ¿las soluciones ESB estan solo al alcance de grandes companias en el mundo? .. lo que no hemos hecho muchos de nosostros es voltear al mundo open source y ver que tenemos alternativas realmente interesantes como Mule ESB, Celtix, Service Mix, etc.. que bien implementadas se puede obtener un resultado realmente interesante comparado con las soluciones comerciales...
Mas preguntas....¿Como poder justificar una compra de una herramienta que cuesta millones de pesos? ¿Como justificar realmente el valor del modelo SOA? ..... para los que estan trabajando en dependencias gubernamentales (y con esto del decreto de austeridad) ..¿ como se puede de verdad reducir costos anuales de uso de licencias de software?...... quiza estas respuestas estan en las soluciones opensource ... ¿sera?
Bueno pues aqui les dejo una interesante entrevista en la que habla Ross Mason fundador de Mule ESB, acerca del rol de los ESBs...
Por una integracion mejor, hasta la vista!!
Tuzo... Campeon
domingo, 10 de junio de 2007
Otras formas de innovación
Como ya varios saben, soy lector regular del blog de Scott Hanselman. Es un tipo realmente brillante no solo tirando código sino llevando la tecnología a nichos que simplemente dejamos pasar de largo.
¿Cuántas veces se ha utilizado Google Earth para buscar monumentos, la casa de tu novia o una dirección? Peor aún ¿cuántas veces no se ha usado para buscar gente desnuda tomando el sol en el patio de su casa?. Puede ser divertido pero definitivamente es un desperdicio de tecnología.
Pues bien, Scott publicó un post sobre como utilizar Google Earth o Virtual Earth para visualizar un nuevo fraccionamiento.
Lo interesante de esto es que son herramientas que están al alcance de cualquier persona. No necesitas ser un mega-dooper-super experto en AutoCAD o cosa similar (claro, el resultado tampoco es igual), simplemente con unas pocas herramientas en tu PC casera consigues el resultado.
Eso también es innovación. Los mexicanos nos preciamos mucho de ser ocurrentes, tal vez alguien acá de este lado de la frontera tuvo la misma ocurrencia. Pero al no compartir ese conocimiento cualquier otro que sí lo hace se convierte en innovador por ese simple hecho.
Estamos muy acostumbrados a construir nichos y compartir un poquito de conocimiento con otros para convertirlos en nuestros aliados. Armamos batallas de escritorio para tirar los nichos de otros. Negociamos con el conocimiento como con cualquier baratija.
Entonces ¡compártamos nuestro conocimiento! Una de las bellezas del software libre es ese ambiente de compartir, de buscar a quién ofrecerle (sin ningún interés por detrás) lo último que construimos, de pedir opinión a otros para mejorar, de mirar en el trabajo del vecino para buscar una segunda opinión sobre lo que estamos haciendo.
Busquemos compartir en lugar de aislar. Tratar el conocimiento, simple o formalizado, con el valor que se merece. Tratemos a los demás como compañeros de creación.
Finito.
¿Cuántas veces se ha utilizado Google Earth para buscar monumentos, la casa de tu novia o una dirección? Peor aún ¿cuántas veces no se ha usado para buscar gente desnuda tomando el sol en el patio de su casa?. Puede ser divertido pero definitivamente es un desperdicio de tecnología.
Pues bien, Scott publicó un post sobre como utilizar Google Earth o Virtual Earth para visualizar un nuevo fraccionamiento.
Lo interesante de esto es que son herramientas que están al alcance de cualquier persona. No necesitas ser un mega-dooper-super experto en AutoCAD o cosa similar (claro, el resultado tampoco es igual), simplemente con unas pocas herramientas en tu PC casera consigues el resultado.
Eso también es innovación. Los mexicanos nos preciamos mucho de ser ocurrentes, tal vez alguien acá de este lado de la frontera tuvo la misma ocurrencia. Pero al no compartir ese conocimiento cualquier otro que sí lo hace se convierte en innovador por ese simple hecho.
Estamos muy acostumbrados a construir nichos y compartir un poquito de conocimiento con otros para convertirlos en nuestros aliados. Armamos batallas de escritorio para tirar los nichos de otros. Negociamos con el conocimiento como con cualquier baratija.
Entonces ¡compártamos nuestro conocimiento! Una de las bellezas del software libre es ese ambiente de compartir, de buscar a quién ofrecerle (sin ningún interés por detrás) lo último que construimos, de pedir opinión a otros para mejorar, de mirar en el trabajo del vecino para buscar una segunda opinión sobre lo que estamos haciendo.
Busquemos compartir en lugar de aislar. Tratar el conocimiento, simple o formalizado, con el valor que se merece. Tratemos a los demás como compañeros de creación.
Finito.
miércoles, 6 de junio de 2007
Software Factories & SOA
El concepto de Software Factories, planteado por Jack Greenfield plantea un modelo para construir software a partir de combinar modelos, herramientas, patrones y frameworks que permitan automatizar el desarrollo de software. Este diagrama que pongo, es la ruta de lectura del libro
La idea es, en lugar de poner en documentos todo el proceso, hacerlo vivir por medio de un software factory.
Es posible hablar del concepto de un software factory que permita automatizar el proceso de implantar un sistema de nomina o inventario. Es como dar una plantilla de un proceso y ajustarlo al punto en particular. Este concepto puede tumbar a los ERPs facilmente, o mejor, ojala los gigantes de los ERPs lo pudieran entender
Pero voy a un punto interesante, y continuando mi entrada de "ideas, ideas"
Estaba pensando ultimamente en un IDE que permitiera completar todo el ciclo de SOA, es decir, con un wizard que funcione asi
1. Tomar una aplicación existente de tu organización y hacer que se convierta en un servicio
(dar next)
2. Seleccionar, la infraestructura de SOA en la que va a ser publicado:
+ Como servicio del ESB
+ Como dato del ISB (information service bus)
+ Como regla de negocio del Rule Engine Broker
+ Como metadato del Registro UDDI
+ Como documento del repositorio documental
+ Como servicio de presentacion (mashup) del portal
+ Como proceso de negocio en el repositorio del BPM
(seleccione uno o mas)
3. Seleccionar las funciones de la aplicación que van a ser exportadas
4. Opciones avanzadas, personalización por cada tipo de servicio a ser publicado
5. Dar Finish para generar servicios
¿Que facil suena?
Ya me imagino la complejidad del pseudocaso de uso que acabo de narrar. De entrada el IDE va a necesitar varios GB de RAM para ejecutarse
Creo que la idea no debe ir por ahi
Cada opcion del "Wizard" que indico, equivale a un proceso de desarrollo para generar componentes de integración. En este blog hemos hablado de los antipatrones, y por supuesto hay patrones para construir dichos componentes
Entonces, por que no hacer un software factory por cada tipo de servicio, es decir, por dominio del problema y que plasme los patrones, frameworks que hemos hablado
Cada software factory, al ser una plantilla puede irse ajustando por cada tipo de aplicación que está integrando
Y el software factory ya ajustado, arrojaria distintos tipos de componentes de integración
Asi ya no son necesarios los wizards
Y ahora piensean, los software factories tienen como caracteristica el que se pueden ensamblar entre ellas, se puede hacer un pipeline de factories y se crean software factories compuestas
Es decir, se puede hacer todo un proceso de desarrollo de servicios de integración a partir de software factories
¿Ya esta la visión, ahora quien empieza a concretar?
La idea es, en lugar de poner en documentos todo el proceso, hacerlo vivir por medio de un software factory.
Es posible hablar del concepto de un software factory que permita automatizar el proceso de implantar un sistema de nomina o inventario. Es como dar una plantilla de un proceso y ajustarlo al punto en particular. Este concepto puede tumbar a los ERPs facilmente, o mejor, ojala los gigantes de los ERPs lo pudieran entender
Pero voy a un punto interesante, y continuando mi entrada de "ideas, ideas"
Estaba pensando ultimamente en un IDE que permitiera completar todo el ciclo de SOA, es decir, con un wizard que funcione asi
1. Tomar una aplicación existente de tu organización y hacer que se convierta en un servicio
(dar next)
2. Seleccionar, la infraestructura de SOA en la que va a ser publicado:
+ Como servicio del ESB
+ Como dato del ISB (information service bus)
+ Como regla de negocio del Rule Engine Broker
+ Como metadato del Registro UDDI
+ Como documento del repositorio documental
+ Como servicio de presentacion (mashup) del portal
+ Como proceso de negocio en el repositorio del BPM
(seleccione uno o mas)
3. Seleccionar las funciones de la aplicación que van a ser exportadas
4. Opciones avanzadas, personalización por cada tipo de servicio a ser publicado
5. Dar Finish para generar servicios
¿Que facil suena?
Ya me imagino la complejidad del pseudocaso de uso que acabo de narrar. De entrada el IDE va a necesitar varios GB de RAM para ejecutarse
Creo que la idea no debe ir por ahi
Cada opcion del "Wizard" que indico, equivale a un proceso de desarrollo para generar componentes de integración. En este blog hemos hablado de los antipatrones, y por supuesto hay patrones para construir dichos componentes
Entonces, por que no hacer un software factory por cada tipo de servicio, es decir, por dominio del problema y que plasme los patrones, frameworks que hemos hablado
Cada software factory, al ser una plantilla puede irse ajustando por cada tipo de aplicación que está integrando
Y el software factory ya ajustado, arrojaria distintos tipos de componentes de integración
Asi ya no son necesarios los wizards
Y ahora piensean, los software factories tienen como caracteristica el que se pueden ensamblar entre ellas, se puede hacer un pipeline de factories y se crean software factories compuestas
Es decir, se puede hacer todo un proceso de desarrollo de servicios de integración a partir de software factories
¿Ya esta la visión, ahora quien empieza a concretar?
martes, 5 de junio de 2007
FONASOL: Pendiente
Pues bien, el FONASOL concluyó el sábado y ya tengo un bonche de recuerdos más que atesorar, nuevos amigos que conocer y algunas fotos que compartir.
Definitivamente es una historia para contar por episodios. No se desconecten.
Finito.
Definitivamente es una historia para contar por episodios. No se desconecten.
Finito.
lunes, 4 de junio de 2007
Web Services Manejables
Hola que tal! de nuevo por aqui
Como se habran dado cuenta, hace algunos dias hablamos (o nos quejamos jeje ) del diseno de unos servicios web.... aqui les dejo unas recomendaciones (Best Practices) a tomar en cuenta, quiza sean simples... pero elementales.. aunque muchas ocasiones no se siguen ;)
Va pues, comentarios bienvenidos :)
Por una integracion mejor, hasta la vista!
Tuzo
Como se habran dado cuenta, hace algunos dias hablamos (o nos quejamos jeje ) del diseno de unos servicios web.... aqui les dejo unas recomendaciones (Best Practices) a tomar en cuenta, quiza sean simples... pero elementales.. aunque muchas ocasiones no se siguen ;)
- NO usar elementos simples en las firmas de los metodos ; tomando como ejemplo public int obtenerCotizaciones(int nss), tenemos un problema: la escalabilidad del mensaje, si desearamos agregar la fecha de alta trendriamos que colocarlo de la siguiente manera public int obtenerCotizaciones(int nss,long fecha).. MAL , en lugar de eso debemos modelar un objeto que defina mi negocio (tanto entradas como salidas).... siguiendo con el ejemplo definamos:
- public class entradaCotizaciones {
private int nss;
private long fecha;
} - public class salidaCotizaciones {
private int numeroCotizaciones;
private boolean error;
private int codigoError;
private String descripcion;
} - public salidaCotizaciones obtenerCotizaciones(entradaCotizaciones entrada)
- Usar Built-Data Types al disenar el XSD del servicio
- Si se pretende utilizar mensajes estandar (Hl7, eGov, xCIL, XNAL), evitar el uso de anyType en el envio del mensaje, es recomendable generar un modelo de negocio basado en los XSD que vienen con el estandar.
- Muy importante, definir los elementos para el manejo de errores, que permitan manipular la respuesta de acuerdo a las condiciones que se presenten
- private boolean error; // describe si existie o no error
private int codigoError; // indica el tipo del error
private String descripcion; // describe que fue lo que sucedio
Va pues, comentarios bienvenidos :)
Por una integracion mejor, hasta la vista!
Tuzo
Suscribirse a:
Entradas (Atom)