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.

Anuncios

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.