Como primer paso para poder poner en marcha este proyecto, voy a tratar de ordenar los comentarios recibidos hasta ahora. Las respuestas puestas aquí son para la discusión del equipo.
Aquí van los comentarios
C1.- ¿El proceso no es demasiado waterfall? ¿No sería mejor pensar en iteraciones rápidas e ir publicando todo en CodePlex desde el inicio? Me parece que es más dinámico y todo avance irá en función al feedback que se obtenga -más allá de los objetivos iníciales que se establezcan.
Tienes toda la razón en el proceso “WaterFall”. Mi idea era hacer un proyecto pequeño, de alcance limitado por lo que no pensé en varias iteraciones. La razón de esto es que además de hacer el software la mayoría de los miembros del equipo no ha trabajado en un proyecto así. Me refiero a un proyecto de código abierto, con un equipo distribuido, etc.
Ahora, podemos fijar objetivos más amplios para el ESB y ponerlo en varias iteraciones. Me parece una buena idea. (Propuesta 1)
C2.- Me confunde un poco la idea de un Enterprise Service Bus para empresas pequeñas. ¿Cuál es la funcionalidad que tienes en mente? No conozco demasiadas empresas pequeñas que tengan problemas de integración que justifiquen esto. ¿Tienes una lista de requerimientos de alto nivel?
La idea de hacer un USB para pequeñas empresas es justamente darles una herramienta para que puedan construir “funcionalidad compartida” para diferentes aplicaciones. Es decir Servicios.
La funcionalidad que tengo en mente es (Propuesta 2):
1.- Catalogo de Servicios: Publicar servicios.
2.- Un despachador implementado en un Pipe And Filter.
3.- Filtros de autentificación, autorización y Traza.
C3 – Basarse en BizTalk creo que te dejaría fuera del alcance de cualquier empresa pequeña. El costo de licenciamiento es enorme. Lo que podría usarse eventualmente es BizTalk Services, aunque es algo en etapa de prueba aun.
Estoy de acuerdo usar BizTalk es mala idea, mejor usamos lo que viene con el Framework 3.0 (Propuesta 3)
C4 – Debiera haber una lista de cargos o tareas para que sean repartidas/asignadas/elegidas (?)
Para este proyecto usaremos una herramienta de colaboración como CodePlex [1]. Esta herramienta define los siguientes roles (Propuesta 4):
Rol1.- Anonymous
Rol2.- Logged-In
Rol3.- Developer
Rol4.- Coordinator
Las tareas las serán definidas por el equipo y la asignación será por acuerdo. Si no existe acuerdo en algún punto podemos votar como método de asignación. Aquí retomo algo que declaré en el segundo Post de este proyecto [2] "cumplir con los compromisos que asuman". Nadie será obligado a hacer algo, los compromisos son personales.
C5- Una de esas tareas inmediatas sería hacer un sitio/grupo propio del proyecto y por ende…
Sí, podemos usar CODEPLEX[1]. Yo ya creé el siguiente sitio para el proyecto:
http://www.codeplex.com/miniESB
Para poder darles acceso, necesito que se inscriban como usuarios codeplex. Este sitio permite hacer discusiones, compartir fuentes, etc.
C6- Hay que darle un nombre al proyecto
En este punto no tengo propuesta. Pueden darle el nombre que quieran 🙂
C7 – Felices vacaciones. …también eres de los que en sus vacas no puede estar sin desarrollar?
Muchas gracias, fueron unas buenas vacaciones pero muy cortas. 😉
Esos son los comentarios recibidos hasta ahora.
Durante “los comentarios sobre los comentarios” puse 4 propuestas, las cuales me gustaría validar con ustedes equipo. Las pueden ver fácilmente en el texto porque están marcadas con (Propuesta N).
Eso es todo por ahora, seguimos trabajando y quedo atento a sus comentarios.
Referencias
[1] Codeplex, http://www.codeplex.com
[2] Segndo Post, http://liarjo.spaces.live.com/blog/cns!4131EA552C5BB029!2266.entry
..:: Liarjo of Locksley ::.. 
Juan Pablo y equipo:
Estuve investigando sobre las topologías de integración y encontré el siguiente link:http://msdn2.microsoft.com/en-us/library/ms978583.aspx
Corríjanme si me equivoco al pensar que un ESB es un Message Bus súperdesarrollado por así decirlo.
Propuestas ya las funcionalidades de:- Catálogación/publicación de servicios- Despacho vía pipe and filter- Filtros de autenticación, autorización y traza
Lo siguiente que me pregunto es… en que difiere esto, aparte del dinamismo de los filtros, de un servidor proveyendo servicios web?Creo que la respuesta es que no existirá un único punto de servicio (y falla), sino que habrá un conjunto organizado de servidores que harán las veces del "Bus" (además que uno sólo sería más bien un message broker).
El patrón del message bus habla de tres tipos de bus basados en publicación/suscripción, los cuales expongo y opino:
1. Basado en Emisión (broadcast): Emite los mensajes a todos los nodos, cada nodo filtra lo que no le interesa.Pros: El más simple y fácil de hacer (creo yo). Contras: No es eficiente el escuchar cualquier mensaje que caiga en el bus.
2. Basado en Lista: Mantiene lista de suscriptores a tópicos. Cada mensaje se envía a todos los suscriptores de aquel tópico.Pros: Complejidad media. Contras: Limitada capacidad de acotar las comunicaciones.
3. Basado en Contenido: Por cada mensaje ejecuta una consulta (acá se podría aplicar un pipe-filter) para determinar a qué suscriptores corresponder enviar el mensaje.Pros: El más sofisticado, pues cada cual recibe lo que pide solamente, por ende consume menos recursos de red. Contras: Mayor complejidad de desarrollo y mayor carga sobre los servidores del bus.
Pienso que este último debiera ser el candidato a implementar en el proyecto.
Ahora bien, para soportar algo así creo que habría que definir dos conjuntos de protocolos:- Uno entre consumidores y el bus- Otro entre los servidores que implementan el bus (para por ejemplo sincronizar sus catálogos)
A priori, visualizo algunos componentes a construir pensando que un nodo podría ser al mismo tiempo consumidor y servidor:- Biblioteca para conectarse al Bus: Para que un nodo pueda consumir servicios y publicarlos desde/hacia éste.- Aplicación ó Biblioteca para proveer el Bus: Realizará publicación/suscripción, aplicación de pipes-and-filters, autenticaciones, actualización y coordinación entre servidores, balanceo de carga (?)…
…si se me arranca la moto y ya no aplica el prefijo "mini" al ESB, avísenme.
Gracias por sus comentarios.
Pasando a otro punto. Estoy registrado en CodePlex como "nmarcel" pero al entrar al proyecto "miniESB" me dice que aún no está publicado y que debo registrarme (bug).Si debes registrarme tu como administrador te ruego que lo hagas.Saludos,
Néstor.
Hola Néstor,
Vamos por partes.
Primero que me gustaría tratar de aclarar es “un ESB es un Message Bus súper desarrollado”
Me parece que no.
Un bus de mensajes está orientado al manejo de “mensajes”, la idea es en este tipo de implementaciones es que el “Emisor” envía un mensaje al bus y todos los “Receptores” interesados se hacen cargo del mensaje.
Un ESB no expone un canal para “gritar” (mandar un mensaje) sino que expone funcionalidades. Es decir habilita la relación “Cliente” que consume “Servicio/funcionalidad”. Cuando un “Cliente” llama al ESB sabe que funcionalidad quiere ejecutar, esto lo sabe por el contrato y políticas del servicio. Por otra parte, en el modelo del bus de mensajes, el “Emisor” avisa de un evento de negocios (mensaje) pero no tiene claro (necesariamente) que funcionalidad se activará con ese aviso.
La diferencia es sutil. La confusión entre los dos es común, porque en rigor usando cualquiera de los dos se pueden forzar implementaciones funcionales parecidas.
Segundo punto, “Lo siguiente que me pregunto es… en que difiere esto, aparte del dinamismo de los filtros, de un servidor proveyendo servicios web?”
La principal diferencia entre usar una funcionalidad a través de un Web Services o un ESB no se ve del lado del cliente (en este caso Mini ESB) sino del lado del servidor.
Del lado del servidor con el ESB logras manejar completamente la ejecución del servicio. Esto porque el servicio está “Alojado” y administrado por el ESB. Este último dirige como se van a comportar los servicios. Por ejemplo, el tamaño máximo del mensaje de respuesta o si está cifrado o no un dato de la respuesta.
Esto último es lo más importante, el ESB ayuda a “gobernar” el universo de servicios. (Que explicación más poética)
Tercer punto, las piezas a construir.
Tú propone construir las siguientes piezas:
A.- Biblioteca para Conectarse.
B.- Biblioteca para el Bus.
Como este no es un bus de servicios, creo que las piezas a implementar serían:
1.- Controlador del Pipe&Filter
2.- Filtro base, que permita extender todos los filtros que uno quiera.
3.- Filtro “Servicio Base”, que está basado en el punto 2 pero es especifico para implementar un servicio.
4.- Filtros “autentificación”, #autorización”, “Instrumentación”.
5.- Servicio de Ejemplo.
6.- Cliente de Ejemplo.
Respecto ah hacer una librería para conectarse, no creo que sea necesario, porque si usamos WCF, entonces al exponer el servicio los clientes pueden generar el proxy de manera automática. Es más si exponemos una interfaz MEX de WCF pueden hacerlo de manera dinámica.
Por último, ya te dí de alta del el proyecto en CODEPLEX.
Señores que quieren participar en este proyecto, inscríbanse en CODEPLEX y me mandan su usuario para así poder darlos de Alta en el Proyecto MiniESB.
Saludos a todos y me parece excelente que está discusión ya se esté armando.
Salu2
Hola Juan Pablo, en esta Etapa Inicial quería aportar mencionando algunos aspectos que deberían ser considerados como Alcances al proyecto:
“Transporte fiable” el cual sería un módulo de tipo Middleware que emplee mecanismos de “almacenamiento” y “reenvío” para garantizar la entrega de los mensajes en caso de anomalías Ej.: anomalías en la red.
Otro alcance, a lo mejor obvio es la “transparencia de las ubicaciones” de los servicios para que el cliente que invoque un servicio solo necesite saber que el servicio existe, o sea que el cliente no sepa donde se ejecuta el servicio. El ESB (“Hermes” boto para nombre de proyecto) localiza el servicio cuando se invoca.
“Soporte a distintos protocolos”. Bueno, pienso que esto será WCF ya que el ESB debe soportar muchos tipos de transporte (http, soap, jms y transportes propietarios de otras aplicaciones empresariales) para integrar sistemas dispares y el transporte de comunicación.
Bueno aparte de proponer un nombre al proyecto, espero aportar con estos alcances para esta primera etapa que son los alcances y visiones.
Nota: también se puede nombrar como alcance es la “Fiabilidad del Servicio”Otra nota: mi usuario de codeplex es rogeliovp
Hola,
ya estan dados de altas en CODEPLEX!!!!
Coordinators
liarjo
Developers
Luison
nmarcel
rogeliovp
Señores , mandenme sus usarios CODEPLEX para agregarlos al proyecto.
Rogelio, continuemos la discución en el foro del proyecto.
To the global wow gold the cheapest wow power leveling under the cheapest single-site! -66340426019494