Archivos Mensuales: octubre 2006

“Service-Oriented Analisys”.

Un enfoque de análisis especialmente pensado para proyectos de arquitectura orientada a servicios SOA.

 

El  objetivo es determinar el alcance de la iniciativa SOA. En la capa de servicios serán definidos e individualizados los servicios candidatos a ser implementados en el proyecto de integración.

 

El proceso de determinación de cómo se representan en Servicios los requerimientos de automatización de los procesos de  negocio, es dominio del análisis orientado a servicios. Las primeras preguntas a ser resueltas son:

 

Ø       ¿Qué servicios necesito construir?

Ø       ¿Qué lógica puede ser encapsulada en cada servicio?

 

Los objetivos superiores de desarrollar este proceso de análisis orientado a servicios son:

 

Ø       Definir las operaciones (funciones) candidatas.

Ø       Agrupar las operaciones en contextos lógicos. Estos contextos son los servicios candidatos.

Ø       Definir preliminarmente las fronteras de los Servicios para evitar solapamiento entre Servicios existentes o planeados.

Ø       Identificar lógica de negocio con potencial de re-uso

Ø       Asegurarse de que el contexto de la lógica encapsulada sea apropiado para el uso previsto.

Ø       Definir cualquier conocimiento de los modelos de composición preliminar de las aplicaciones.

 

El sub proceso de análisis tiene las siguientes etapas:

 

1.     Define business automation requeriments

 

Para lograr una buena definición de los servicios candidatos es necesario contar con requerimientos de negocio lo suficientemente maduros. Para asegurar esto, se realiza está etapa que apoya a la definición formal de los requerimientos de negocio.

 

2.     Identify existing automation systems

 

Se deben identificar la lógica de aplicaciones existente, a ser extendida o automatizada para satisfacer las necesidades de negocio identificadas en el punto 1.  En este punto del análisis orientado a servicios no se determinará cuales serán exactamente los Servicios a construir sino que se pretende identificar los sistemas que potencialmente serán afectados.

 

3.     Model Candidate Services

 

El análisis orientado a servicios introduce el concepto “Service Modeling Process” por el cual las operaciones candidatas son identificadas y agrupadas en contextos lógicos propuestos. Esta propuesta se convierte en los servicios candidatos que eventualmente se convierten en servicios en las etapas de implementación del proyecto.

Volver

Después de varias películas de drama de Almodóvar, llega está cinta que regresa a la comedia. Es una muy entretenida.
 
Está película enfrenta a la muerte con toda naturalidad, siendo llevada adelante por las mujeres. La música es conmovedora, el tema de Gardel interpretado (mas bien doblado) por Penélope Cruz (que sale guapísima) es hermoso.
 
Es absolutamente recomendable.

Guía turística en español de Nueva York – guiadenuevayork.com

New York City es una ciudad increíble.

Es tan impresionante que me siento un campesino en su primera visita a la gran ciudad.

Lo he pasado súper bien J pero estoy raja de tanto caminar.

Este sitio es buenísimo para saber qué es qué y dónde hay que, se los recomiendo.

Link to Guía turística en español de Nueva York – guiadenuevayork.com

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.

Building an ESB on the Microsoft Plataform

 

Débil la presentación, explican lo que ya se sabe. Lo bueno es que viene un TOOLKIT (Microsoft ESB Guidance for Partner) para Partenes que servirá para estandarizar las soluciones de ESB.

ESB está vivo, aunque muchos en mi pueblo me dijeron que no.

 

  1. Lo primero es tener claro el valor para el negocio.
  2. Desde el punto de vista del administrador, hay que buscar la mejor forma de integrar las aplicaciones. Se debe evitar las conexiones punto a punto, no se pueden administrar.
  1. ¿Qué es un ESB?
    1. No hay una definición oficial.
    2. Hay acuerdo en algunos puntos:

i. Message Broker

ii. Message transformation

iii. Validación de mensajes

iv. MOM Message oriented middleware.

    1. Es una parte importante para armar una arquitectura SOA.
  1. Infraestructura de SOA
    1. Soportar proveedores y clientes.

i. CIM: interfaz de cliente común.

ii. SIM: Interfaz de servicio común.

    1. Componentes de ESB

i. Orquestación.

ii. Trasformación.

iii. Routing

iv. Exception managment

1. En un MOM, se deben generar mensajes de excepción que son recibidos por las aplicaciones usando P/S.

2. Se generan Handler genericos.

3. EL handler se basará en una orquestación re usable.

4.

    1. Registro de servicios.

i. Bussines Services Console es necesario!!!! No hay producto MS para esto.

    1. Mangment de servicios.

i. Monitores de healt.

ii. MOM

iii. LOG.

    1. Seguridad.
  1. Anuncio: Microsoft ESB Guidance for Partner
    1. BST 2006
    2. Guías de arquitectura.
    3. ESB core Engine.

i. On/off Ramps.

ii. Intermediary Functions

iii. Standarized metadata “envelope”

iv. Mecanismos de resolución: cuando de se recibe un mensaje, se debe resolver que hacer con él.

1. Cuando no es posible resolver, se debe enviar la excepción. Dead letter es l concepto aquí.

v. Provisioning and administartion

    1. Simples On/Off Ramps
    2. Framework con WSS 3.0