Archivo de la categoría: SOA & Business Process Conference

Windows Azure Queues and Windows Azure Service Bus Queues

Aquí publico una pequeña comparación de las opciones de mensajería de Windows Azure, con foco en Services bus Queues y ejemplos transaccionales que compilé la semana pasada para un proyecto en México.

Lo que necesita el proyecto es poder habilitar mensajería transaccional entre servidores en sus instalaciones y servicios corriendo en la Nube. Aquí se incluye un ejemplo de cómo enviar mensajes desde una cola MSMQ a una Cola del Service Bus en Azure de manera transaccional.

Links relacionados

  1. Colección de EBooks GRATIS de tecnologías Microsoft, incluida Windows AZURE
  2. Mejores Prácticas para el Diseño de la arquitectura en CLoud
  3. Presentación: Introducción SOA

 

Anuncios

Presentación: Introducción SOA

Una presentación de introducción a SOA

Algunos post de SOA

  1. Service Registry: A Key Piece for Enhancing Reuse in SOA
  2. La conferencia de SOA que cambió el mundo
  3. ¿Qué tópicos se deben incluir en un proyecto de SOA?
  4. Definición de proceso SOA Assessment

Connected Systems on Windows: Presentation

Steve Swartz, Architect

Clemens Vaster, Program Managaer

Connected System Division

Estas es la cuarta presentación de la serie, solo he visto 2,5 😦

Client Pattern

Ø Clientes conectados: solución simple.

Ø Message Editor: un ejemplo es InfoPath. En al interfaz se hace el mensaje y después es enviado y la magia ocurre.

Ø Data Viewer: la aplicación tiene los datos locales, todo se ve fácilmente.

Ø Local Analysis: La aplicación recibe datos, la aplicación usa la data y la entrega a la lógica de negocio y recibe una nueva respuesta.

Ø Aggregator: La capa logica obtiene datos de diferentes fuentes y los agrega para la aplicación cliente.

Ø Full Interaction: lo hace todo, los 3 patrones anteriores combinados. La diferencia es que no exite un solo controlador de los cambios en los datos, aumentando la dificultad.

Connected Patterns

Ø Identity: quien soy.

Ø Network Segmentation: Divide y vencerás 🙂. Este es un aspecto que no puede ser dejado de lado al hacer aplicaciones conectadas. Por ejemplo la fortaleza de SKYPE es el manejo de la conexión y no la compresión de audio y video. El concepto de RELAY se usa aquí porque los mensajes pasan de red en red.

Ø Metadata: Data que describe la data. La idea es tener servicios de descubrimiento de servicios o lo que sea, es decir directorios. Esto puede ser federado, no es necesario que toda la data sobre la data este concentrada, si es federada escala al infinito.

Ø Discovery: descubrimiento del recurso que se necesita, hay lógica en esto ya que no es responsabilidad del que busca saber cual es la mejor forma de llegar al recurso.

Connected Scenarios

Ø Restaurant Search: Es una serie de filtros hasta llegar a los datos. Por otra parte, hay que tener data y metada. Si es usado desde el Web no se presenta la misma información que si se usa en Smart Phone. Esto es responsabilidad de la lógica de presentación.

Ø Law Firm:

Ø Email: Outlook/Exchange/OWA es una combinación vista dirigida por mensajes. Tiene Relay, identity, naming, directory.

Ø Global BAnk Loans: es un clásico ejemplo de ESB complementado por Relay, Identity, Naming y Directory.

Ø Chats and Calls: personas inician por mensajes, con interacción directa (Relay, Identity, Naming y Directory), manejo intensivo de network segmentation.

Ø Halo XBOX Live: es el mismo escenario que el anterior, los juegos en red.

Ø Voice Mail: (buzón de voz del celular) Los mensajes entran, activan el flujo. Se almacenan y después de despachan al celular.

Takeaways

Ø La tecnología de clientes conectados abren un nuevo mundo de oportunidades.

Ø Se tienen mas oportunidades de las que se pueden aprovechar.

Ø Tome la opción correcta para cada caso.

Connected System on Windows: DATA

Steve Swartz, Architect

Clemens Vaster, Program Managaer

Connected System Division

 

Cuando se habla de Arquitectura de datos, los arquitectos junior quieren un libro de cocina. Esto por definición es un error.

Las aplicaciones tradicionales no necesitan arquitectura de datos, si las nuevas distribuidas. Shared Data es el tema. Con esto ocurre que los datos dejan de ser de la aplicación y pasan a ser compartidos.

En este punto comienza la colaboración y llegan los nuevos desafíos para la arquitectura de datos.

Existen diferentes tipos de bases de datos.

Reference Database, en este modelo toda la organización la usa. La mayoria de los sistemas lee desde estas bases, pero solo algunas escriben, por eso es una base de referencia. Tiene problema de latencia de los cambios de datos.

Fresh Data, en estas bases todo el mundo quiere leer los datos actualizados. Por ejemplo precios o valores de la bolsa. Aquí el punto principal es que los datos DEBEN estar actualizados, esto es un problema para los arquitectos porque es muy caro lograrlo.

Stale Data, Cada aplicación tiene sus datos y de manera Batch los lleva a una base central. Esto es un problema del mundo real, pasa todo el tiempo. Los desafíos en esto son el manejo concurrente de los datos y la sincronización. El estado de los datos es una “creación” de lo que la arquitectura de datos defina.

Huge Data, las aplicaciones para estas bases de datos deben pensar que cada registro es una base de datos :O, esto porque estas bases están en muchos Server y cada registro puede estar en cualquier parte.

Distributed Database, aplicaciones con muchas bases diferentes. Por ejemplo si quieres leer una entidad de diferentes bases debes hacer un pool de los datos y agregar la entidad.

Patrones acceso a Datos

Ø Access Direct

Ø Access Remote

Ø Access Intermediated: un patrón muy poderoso. Tiene una capa de soporte a aplicaciones que puede tener mucha flexibilidad y control del acceso a los datos.

Patrones de manejo de errores

Ø Error ACID: relativamente facil implementar aplicaciones así. Pero es terriblemente costoso por los bloqueos de los recursos.

Ø Error Accountig: La capa intermedia de acceso a los datos, si hay un error lo manda a un LOG. Esto hace que sea extremadamente rápido y sin bloqueos

Ø Errors Compensation: acciones de modificación y corrección de los datos. Ambos son código hecho específicamente. Esto es el mejor patrón para aplicaciones distribuidas.

Los tres patrones Error son para enfrentar las posibilidades de conflictos en bases de datos.

Patrón de distribución de datos

Ø Distribution Caching: acceso rápido, para aplicaciones.

Ø Distribution Federation: cuando se tienen varias bases, una base “concentra” los datos de las otras para mostrarla a la aplicación. Esta composición es una agregación lógica. Los problemas de concurrencia son controlados por esta base de datos. Típicamente con compensaciones. Esto no es fácil, cuando las bases son de solo lectura es trivial. Biztalk es un buen implementador de esto, porque con una orquestación puede coordinar los cambios en todas las bases.

Ø Distribution R/O Replication: replicación de datos hacia las aplicaciones. Solo lectura. Reduce la latencia y las fallas en el acceso a los datos. Esto porque los datos “estan cerca” de la aplicación. La diferencia con CACHE es que en este caso el Server pasa (fuerza) los datos al cliente, mientras que en cache el cliente tiene una copia que el obtuvo.

Ø Distribution R/W Replication: lo mas difícil de lograr. Las aplicaciones tiene copias cercanas de los datos y pueden cambiar los datos de manera distribuida. Temas a tener en cuenta: se pueden caer las bases, cada cliente tiene diferentes copias de los datos activas.

Ø Distribution Reporting: Esto es una lectura del estado de los datos, desde diferentes fuentes de datos. Esto es hacer copias de solo lectura para acceso rápido.

Los escenarios.

Ø Outlook / Exchange: calendar, contacts, Drafts y Task es fresh porque es manejado por la aplicación para cada usuario.

Ø Game: estos son ambientes muy volátiles, de acceso rápido a los datos. Share Store con vistas rápidas y “parciales” de los datos.

Ø Bank Machine: Tiene un intermediado para ir a los datos, porque usted puede acceder a cualquier banco. Es una federación.

Ø Hotmail: Existe una base Índice y un montón de bases con los datos. Load Manager administra la base índice. Es una base distribuida, federada en la indexación. Cada mail (registro) es tratado como una base de datos particular, muy interesante idea. Esto es recomendable cuando se maneja mucha información para cada persona.

Ø Identity Integration: Microsoft Identity Integration Server. Es un concentrador de identidad. Existen muchas bases de datos y este Server tiene concentrado una vista única para la aplicación de todas las bases. Es una federación.

Ø Active Directory: replicación activa de bases de datos.

Takeaways

Ø Toda la data es diferente.

Ø El acceso a los datos puede ser dividido en patrones simples.

Ø La arquitectura de datos correcta es al final la optimización del desempeño.

Developer Q&A Panel

 

Muy bueno, aqui todos los participantes chachan un kilo no como en mi pueblo.

Interesante que todos pidan un adaptador BizTalk J2EE y los developer digan que no esta en el RoadMap porque no es imposrante.

1. Patrón de Binding Orquetration ¿Qué pasa con muchas colaborando? ¿Están acopladas? ¿Cuáles son las buenas prácticas para este caso?

Es lo mismo que antes, por ejemplo el uso de colas y datos temporales.

Se tienen dos opciones: hacer todo o usar BizTalk. Si se necesita total control y la forma propia de evitar acoplamiento usar WF.

Si se tiene 20 orquestaciones colaborando, son como cajas negras. Necesitas una controladora. Pero ojo, no existe una regla.

Un buen problema en este caso será el versionamiento. Se necesita tener en cuenta las versiones de los assembly.

2. WCF ¿Cómo se pueden descubrir los endpoint facilmente?

Los clientes se pueden configurar para que tomen el address desde UDDI a través de servicios de UDDI. Programático, el client factory crea el Proxy tomando en cuenta esa información.

3. Windows Services, ¿Cómo hacer un servicio tipo task?

Puedes hacer un wrapper de una task de Windows. Otra forma es SQLScheuler.

4. BizTalk, ¿viene algo como QUEUE en los puertos de salida para confiabilidad?

No se planea hacer nada en R2.

Si el adaptador es WCF, se tienen dos niveles de manejo de errores y mensajería confiable. La confiabilidad en BizTalk la da elMesaggeBox, en WCF la da el protocolo.

5. Filtros dinámicos en la orquestación.

Se puede hacer en los recive port un truco, pero los filtros de orquestación no serán dinámicos.

6. BizTalk Adapters ¿Roadmap?

R2: viene un nuevo framework con WCF listo.

El objetivo es soportar Seabel completamente.

Adaptador J2EE adapter no tenemos, lo tiene el partner.

No viene un adaptador de DICOM, Server ni cliente.

7. Windows activation Services

Es un hosting de servicios. Viene con Windows Vista. Hay documentación en WCF.

IIS7 es Server, WAS es solo para aplicaciones.

8. ¿Por qué podría ser que adaptadores queden freeze?

¿??

9. ¿Cómo se puede alcanzar alta desempeño en IIS con WS?

Se puede hacer tunning del thread pool por ejemplo. Especialmente en el Safe mode.

Ponga una cola después de Web Services.

10. ¿Por qué hay re instalar host de biztalk?

No siempre hay que reinicia, hay muchos cache en Biztalk, sería suficiente con reiniciar el cache.

11. ¿Qué aplicaciones pueden ser host de WF?

Cualquiera .NET, Office, etc in the future.

12. En comunicación Biztalk to biztalk ¿por qué no usar submit direct?

Lo único que no se recomienda es tenerlos conversando usando puertos si son del mismo grupo Biztalk.

13. ¿SAP ADAPTER IDOC para transacciones?

Para llamar una orquestación desde SAP que es transacción no se puede usar IDCO ¿why?

No se soporta por la limitación de los conectores implementados en .NET.

Implementing Change Data Capture as an Event Source SOA

 

La idea es lograr capturar cuando hay cambios de datos en los sistemas LOB que participan de la arquitectura SOA.

Para poder hacer CDC se necesita tener un agente que este observando lo que pasa con los datos. Este es el patrón “sapo” 🙂  (Fowler lo llama observador)

Algunas consideraciones:

1. CDC: Change Data Capture.

a. KEY Driver of CDC: Data volumens, Data Legacy.

 

2. Event Driven BPM: el CDC activa un BPM.

a. Puede aplicar reglas de negocio.

b. Pueden participar workflow humanos.

3. CDC consideraciones:

a. Históricamente se usaban TimeStamp.

b. La comparación de datos, muy costosa.

c. Uso de Triggers programados.

4. Solución de CDC

a. Leer el log de la DB. (cool)

b. Usar el evento user exit para grabar un los de cambios,

c. Eventos en los programas.

d. Lo que se usa depende de la base de datos, performance y latencia permitida.

5. Impacto en los sistemas de CDC

a. Todas las soluciones tiene impacto.

6. Latencia, un factor clave.

a. Uso de Batch con criterios de tiempo, número de cambios, pull.

b. RealTime, los cambios son propagados de inmediato. Son eventos.

7. Consideraciones cuando se trabaja con LOG

a. Commited and uncommitted changes.

b. Marcas de las transacciones.

c. Cambios redundantes.

d. LOG archivados y activos.

8. Otras consideraciones

a. Soporte de múltiples consumidores del evento.

b. Recuperación de desastres.

9. Business Drivers

a. Mantener data consistente para tomar desciciones en poco tiempo.

b. Soporte de dachboard en tiempo real.

 

10. Legacy Integration Challenges

a. Interoperabilidad.

b. Metadata y mapa de datos.

c. Complejidad y diversisdad.

d. Seguridad.

e. RAS (Realiability, Availiability, Scalability)

11. Patrones típicos de implementación

a. Legacy data CDC to BizTalk.

b. BizTalk to Legacy Data Source

c. Legacy Business Logia to Biztalk

d. BizTalk to legacy Business Logia.