Desarrollo Agile y ESBs

votos
1

Estoy trabajando en cambiar nuestro paradigma tecnológico corporativo a Agile Development. ¡Ha sido un proceso difícil, pero ya casi llegamos! :)

Contamos con sistemas heredados para nuestra administración de bases de datos (solía ser Access, ahora portado a .NET y MS SQL) y estamos desarrollando un marco para nuestra visión de futuro. Queremos migrar tanto como sea posible a la web. Pero queremos integrar el sistema actual con el próximo. No superponeremos tareas y funcionalidades.

Mi visión es mover toda la información de contacto de nuestros usuarios a una base de datos diferente, vinculando esos perfiles a MS SQL para su historial e información contable. Mantendremos todos los sistemas de contabilidad en la aplicación de escritorio, pero hay muchas más funciones que vamos a agregar que dependerán mucho de la Web, especialmente Ruby on Rails.

Supongo que la pregunta es: ¿por qué los ESB? ¿Hay alguna manera de crear una SOA sin pasar por los sistemas ESB complejos? La idea es KISS de todos modos. ¿Se puede crear una SOA de manera que permita que el escritorio / web / móvil sean interfaces, manteniendo las funcionalidades en la lógica comercial (por supuesto, algunas funcionalidades deberían implementarse en la interfaz, pero manteniéndolas al mínimo). ¿Y los ESB incluso se ajustan a una filosofía Agile? ¡Mientras más leo y estudio, menos creo! : /

Gracias por su entrada gente! Si necesita que lo aclare, solo haga algunas preguntas y haré todo lo posible para hacerlo. :)

Publicado el 09/12/2008 a las 23:51
fuente por usuario
En otros idiomas...                            


3 respuestas

votos
3

Los ESB se adaptan bien con ágil una vez que el marco / infraestructura está en su lugar. Descubrirá que puede crear un nuevo sistema en piezas, ejecutar las nuevas piezas en paralelo con el sistema anterior durante un tiempo, y apagar gradualmente las partes antiguas del sistema hasta que solo quede el nuevo sistema, y ​​nadie lo hará. alguna vez sepas la diferencia

una SOA básica solo define servicios en lugar de aplicaciones; un ESB administra los servicios en canales para ocultar los puntos finales, haciendo las actualizaciones y sustituciones mucho más "ágiles"

Respondida el 10/12/2008 a las 00:24
fuente por usuario

votos
1

Aprendí bastante rápido para evitar el término "ESB" ya que está muy sobrecargado y significa cosas diferentes para diferentes personas (y a veces cosas diferentes para la misma persona :-))

La clave, naturalmente, es preguntarse qué es lo que realmente necesita.

Envolver sus bases de datos como un servicio es una buena elección, especialmente si tiene varios clientes para estos datos; tendrá que pasar una buena cantidad de tiempo pensando en sus contratos y en su alcance, pero ágil puede ser de gran ayuda aquí.

La pregunta ahora es cómo se llama a estos servicios, y creo que debe sopesar la probabilidad de que los clientes y los servicios cambien y cómo evolucionará su sistema.

Un bus de servicio ayuda a enmascarar los servicios de su cliente (que pueden ser otros servicios) y este "enmascaramiento" puede retransmitir a ubicación, protocolo, formatos, códigos, etc. algunas formas de un bus de servicio también mantienen el itinerario (lo que debe ser llamado, y cuándo) pero generalmente no me gusta la idea.

Entonces, la pregunta que debe hacerse primero, creo, es qué necesita para comenzar y cuánta inversión inicial desea realizar (y puede justificar)

Por ejemplo, si inicialmente está satisfecho con un enfoque más punto a punto, sus clientes pueden llamar al servicio directamente; en una etapa posterior, a medida que el servicio evoluciona, puede presentar al "intermediario" para negociar la solicitud y la respuesta (sí, puede llamarlo ESB si lo desea).

Alternativamente, puede comenzar con un "intermediario" básico, de modo que los clientes nunca llamen directamente al servicio, sino que solo tengan las características que necesita para empezar y amplíe sus capacidades a medida que se vayan formulando los requisitos; bien puede comenzar como una simple máquina de reenvío.

Lo ideal sería construir sobre un producto que tenga muchas capacidades incorporadas; BizTalk Server es una buena combinación si estás en MS stack (pero tiene su curva de aprendizaje)

así que - discúlpame si esta no es una respuesta muy concreta - pero supongo que mi punto principal es que "ESB" no tiene que ser una exageración, simplemente se reduce a lo que deseas tener el primer día, y es ágil (y SOA) ) definitivamente ayuda permitiéndote evolucionar gradualmente en lugar de algo parecido a big-bang.

(Si algo de lo anterior es una tontería completa o simplemente no está claro, es debido a la falta de sueño con un recién nacido en la casa! disculpas :-))

Respondida el 10/12/2008 a las 11:40
fuente por usuario

votos
0

Toda la migración es lo que me llevó a los ESB ... ¡Pero la idea de un ESB parece compleja para resolver un problema que involucra unos 30,000 perfiles! Estamos a punto de experimentar un crecimiento exponencial (a unos pocos millones de perfiles) y quizás comenzar un nuevo camino sería lo mejor. ¿Qué tan fácil es vincular una entrada que se encuentra en una base de datos MySQL a datos almacenados en MS SQL DB? No quiero una doble entrada, obviamente, pero podría haber una manera más ágil que un ESB "completo" ... Entiendo que un SOA con un ESB puede ser bastante ágil en términos de actualizaciones y sustituciones, pero ¿sería una exageración? :)

Respondida el 10/12/2008 a las 00:41
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more