Aquí hay 4 direcciones muy buenas con información en este tema

Software as a services MSDN

http://msdn.microsoft.com/architecture/sAAS/

Jesus Rodriguez's WebLog

http://weblogs.asp.net/gsusx/

Gianpaolo's blog

http://blogs.msdn.com/gianpaolo/

Fred Chong's WebBlog

http://blogs.msdn.com/fred_chong/

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.

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.

 

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.

 

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.

 

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.

3. ¿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.

3. Es una parte importante para armar una arquitectura SOA.

4. Infraestructura de SOA
   1. Soportar proveedores y clientes.

i. CIM: interfaz de cliente común.

ii. SIM: Interfaz de servicio común.

2. 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.

3. Registro de servicios.

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

4. Mangment de servicios.

i. Monitores de healt.

ii. MOM

iii. LOG.

5. Seguridad.

5. 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

4. Simples On/Off Ramps
5. Framework con WSS 3.0

<<Lo mejor que he visto hasta ahora>>

Lista de 11  impresionante de TIPS para usar WCF.

Cosas cool:

• El canal wsdualhttp es de jugete, confirmado
• No usar mas XSD para validación de mensajes.
• Una recomnedación muy buena es tener una interfaz de admisitarción común para los servicios.

Expositor :CraigMcMurty, Technical Evangelist

1.- Validación de mensajes.

0.-no validar mensajes con XSD

a.- la performance es mala.

b.- Dentro del canal se debe poner la validación.

c.- también se puede poner en el Message Inspector

d.- Mejor desempeño si se usan clases tipeadas, en el parameter inspector se puede validar los valores.

e.- XSD no tiene buen soporte de herramientas.

 

2.- SOAP FAULT

a.- Existe Fault Contract para falla en la estructura del mensaje.

b.- Fault Execption se ve en el proxy generado, pero no en wsdl.

 

3.- Traza a tarves de varios HOPS de servicios TRracing

a.- WCF puede hacer traza nativamente, con nivel de criticidad

b.- Se puede definir donde poner la traza, en que archivo.

c.- Tools traceview apoya el estudio de los LOG, aunque sean de diferentes puntos.

 

3.- ¿cómo puedo impersonar y mover las credenciales al servidor? Protocol credential

a.- Impesonalisation usando windows identity usando Kerberos/NTNL, en el binding configuration se puede habilitar la impersonalización por configuración.

b.- En el lado del servicio, se debe agregar en el servicio y en el metodo un atributo para permitir la impersonalisación.

c.- ¿Qupé pasa sin no es windows identity?

c.1.- Se debe usar STS, enviar el token y es complicado. En el largo plazo es mejor!!

 

4.- Buenas prácticas para hacer llamadas en el mismo proceso

a.- Esto no es un problema de computación distribuida.

b.- WCF no es para esto.

 

5.- Las mejores prácticas con equivalentes a NO HAGA….

a.- Ojo con los pilotos, no son una solución final J

 

6.- Addresses

a.- Cuando tenga su propio host defina la dirección base pero uso para el endopoint una dirección relativa.

b.- El binding delendpoint pueda cambiar sion cambiar la direccion base.

 

7.- Binding

a.- WSDUALHTTP: no aplica con firewall, NATs y IPv4. Es para demos, pero no tiene aplicaciones prácticas en el real WORLD. En IPV6 será posible.

b.- wsHTTP desabilite los protocolos que no usará.

b.1.- WS-I no está garantizando la intorepabilidad, por ejemplo con BEA.

d.- QUEUED:

d.1.- tiene el limite de tamaño de 4 MB.

d.2.- NO tiene remote recive.

f.- NetTcPBinding: para WCF-TO-WCF

g.- netPeerTcpBinding: solo es para P2P application.

h.- Streaming: se usa para archivos, por ejemplo musica.

h.1.- No está seguro para mandar grandes mensajes.

 

8.- Contratos

a.- ¿Qué pasa con los valores por defecto? Son diferentes de los defectos de ASMX

b.- Solo use tipos de datos que pueden ser resueltos por XSD. No mande DATASET aunque sean tipeados. No interoperan en la práctica.

c.- ContractFirst es una forma de diseñar, ojo con los atributos XML porque no pueden ser serializados en los contratos WCF, solo se deben usar elementos en XML.

d.- Uso de clases parciales (public partial class myDataContract) para los contratos. Los datos en una parte los metodos en otra parcial class. Así es fácil leer como es el contrato.

e.- sobre propiedades publicas y privadas: no hay diferencia en la serialización, si se usa serialización XML deben ser públicos los miembros para que sean considerados.

f.- La sección Header es para datos de protocolo no de negocio. MessageContract da acceso a todo el mensaje. DataContract solo al body del mensaje.

g.- Proveer un FaultContract para cada OperationContract.

h.- Proveer una operación por defecto: Action=”*”.

i.- Trate primero que la comunicación se asíncrona, si no es posible use sync.

j.- La interfaz de administración. Es una interfaz de consulta sobre el estado de la aplicación. Muy útil para saber que está pasando con la operación del servicio.

 

9.- Service Implementation

a.- Para elegir un WebHosting se debe tener en cuenta:

a.1.- Se pueden subir nuevos built?

a.2.- Provee seguridad seria.

b.- cuando uno tiene el hosting, llame expicitamente Close() para mejorar el desempeño.

c.- Implemente los servicios en una DLL independiente. Para poder tener un debugg decente.

d.- Para reducir la latencia y mejorar el desempeño haga:

d.1.- IntanceContextMode=Single.

d.2.- ConcurrencyMode=Multiple.

e.- Para mantener estado: use los mensajes, guarde los datos,

f.- No guarde estados, si lo hace que sea compatrible con ASP.NET

g.- ServiceAuthorizationManagerTypes es el modelo ideal.

g.1.- Es mas general, confiable pero considere el motor de reglas de WF para implemenatar)

 

10.- Client Implementation

a.- Siempre use programación asíncrona.

b.- Reduzca la latencia de la primera llamada usando el método OPen().

c.- Siempre llame el método Close(). Esto acelara el colector de basura.

 

11.- Managment

a.- Use WMI. Turn ON.

b.- Haga un model de health consistente,

b.1.- Deje contadores.

b.2.- Use Event Log.

b.3.- Tenga una interfaz de administración

John Evdemon

Architect, Architecture Strategy

<<Notas sin editar>>

1. Agilidad: la única estrategia sustentable
2. SOA nos habilitará para hacer BPM.
3. Mitos comunes de SOA:
   1. SOA es una tecnología: jajajajajajaja
   2. SOA requiere Web Services: solo son una implementación.
   3. SOA es una nueva revolución: no ya existía por ejemplo EDI, CORBA.
   4. SOA asegura la agilidad: SOA no es una metodología no asegura nada.
   5. SOA reduce el riesgo: es como un copo de nieve, no hay dos iguales.
   6. SOA requiere una nueva tecnología: en rigor puede ser implementada con su actual tecnología.
   7. SOA requiere un ejército de consultores: Se necesitan buenas herramientas no consultores.
   8. Necesitamos construir SOA: esto es un error, lo que se hace son soluciones que están alineadas con SOA no un SOA product.
4. Re Uso
   1. ¿Deja Vu?
   2. El re uso no se ha logrado, no necesariamente se logrará con SOA.
5. Exponer / componer / Consumir
   1. La triada del ciclo de vida de SOA
   2. Aplicaciones compuestas: es una nueva forma de hacer aplicaciones basadas en la asociación de servicios y procesos de negocio.
   3. Exponer: habla de cómo se construyen los servicios, decidir la granularidad es todo un tema no sencillo. Han aparecido patrones para esto.
6. Recurring Logical Capabilities
1. User Interaction: crear mejores aplicaciones.
1. Son necesarios servicios especiales para CBA. Estos soportan las funcionalidades Rich de las aplicaciones.
2. Servicios de Wrappers: muy importantes, exponen temas de LOB a las interfaces de manera simple.
2. Workflow: componer aplicaciones. 
1. Coordinar servicios remotos, procesos largos en el tiempo.
3. Data: obtener datos consistentes. 
1. Servicios de entidad
2. Servicios de agregación 
3. Servicios de Factoring.
4. Identity and Access: aspectos de seguridad transversales. 
1. Manejo de la identidad.
2. Impersonalización y delegación.
3. Modelo Trusted subSystem.
4. Autentificación.
5. RBAC
6. Administración de los relaciones de confianza.
5. Message and Services: esta compuesto por una capa lógica en frente de las aplicaciones.
1. Es necesario determinar ¿Qué exponer?
2. Service Operation Contratcs: administración
3. Message And Data Contracts
4. Versionamiento
7. COMPOSE, los aspectos transversales que apoyan la composición son:
1. User Interface: viene PAGEFLOWS concepto que ya existía en BEA hace dos o tres años, que buena noticia.
2. Workflow: soporte para procesos largos, que siguen a la interfaz.
1. Fáciles de modelar.
2. Fáciles de cambiar, incluso en ejecución.
3. Data: 
1. Traking del estado de los workflow
2. ETL
3. Mensajeria confiable y persistencia.
4. Replicación.
5. Sincronización, para aplicaciones OCC
6. Administración de metadata.
4. Message and Services 
1. Orquestación de servicios es la clave.
2. Las orquestaciones se exponen como servicios.
3. Soporta el patrón de comunicaciones asíncrono.
8. Consume:
1. User Interaction:
1. OBAS, composición de aplicaciones.
2. Personalización de interfaces.
3. Portales
4. BI y reportes.
5. Agregación de contenido: los usarios reciben la información agregada desde diferentes fuentes.
6. UX declarativa: ¿????????
2. Workflow & BPM 
1. Humman workflows (MOSS)
2. Event Broking (CAB)
3. Page Flows
3. DATA 
1. OBA(office Business Application), cómo la aplicación del Banco de Chile / Business Data Catalog (BDC)
2. Una solo vista del cliente!!!
3. JSON: Java script location on XML?????
4. Identity and Access 
1. SSO /RBAC /
2. Servicios de directori
3. Compliance?
5. Messaging and services 
1. Formularios electronicos (infoPath)
2. Web PArts,
3. Registro de servicios (check in / check out /buscar) ¿no esta claro con que hacerlo?
4. AJAX, REST, rest interface permite el dialogo con la interfaz usando servicios.

<<Notas sin editar>>

John deVadoss

Director, Architectura Stragy

1. Web Servicies, vino a satisfacer el sueño de integración fácil.
   1. WS* nuevos estándares del la industria.
2. SOA es un estilo de arquitectura no un producto o tecnología.
   1. El primer beneficio es Agilidad.
   2. Los estándares son críticos para el éxito de SOA.
   3. El foco en el mundo real es Time-to-Value.
3. Existen clientes exitosos y que han fracaso en la adopción de SOA.
4. un ejemplo de necesidad del negocio es “Single View of client”
5. En el mundo real
1. Business Driver
2. Incremental delivery (Expose, Compose, Consume)
3. Service Enablement (Expose) Servicios de aplicación.
4. Compose: Workflow y orquestación.
5. Consumir los servicios: aplicaciones de cualquier tipo.
6. Cuando se ponen las piezas juntas:
1. i. Seguridad.
2. ii. Administración
3. iii. Herramientas
6. ROADMAP de innovación
1. 2007
1. i. Office
2. ii. Windows Vista
3. iii. Office Sharepoint
4. iv. BizTalk 2006 R2
5. v. .net 3.0
2. Después
1. i. Windows Server “Longhom”
7. Enterpice Connectivity
1. BizTalk Adapter
1. i. Muchos adaptadores para la industria.
2. ii. R2:
1. 1. WCF
2. 2. EDI /AS2
3. 3. RFID
4. 4. Otros LOB
5. HOST INTEGRATION Server
6. i. Nuevos adaptadores.
3. ESB Guidance
1. PRe Built, aceleran la implementación.
2. Programas de adopción para ISV.
2. .NET 3.0
1. Windows CardSpace 
1. Registro y Login
2. Integrado con Indigo.
3. iii. Tecnología para las masas.
2. WF
3. WPF
4. WCF
8. The “Last Mile problem”
   1. En el mundo real, las aplicaciones y sistemas no están preparadas para ser integradas. Todo es AD HOC, no fue pensado para integrarse.
9. Links útiles
   1. http://msdn.microsoft.com/architecture/
   2. http://msdn.microsoft.com/practices/
   3. http://msdn.microsoft.com/webservices/
   4. http://www.architecturejournal.net/2006/issue8/
10. ¿Cómo empezar?
    1. Buscar los Business Drivres
    2. Middle-out: busque casos impactantes, demuestre el valor para el negocio.
    3. Partition your business capabilities, esto es un riesgo busque que es lo que realmente puede hacer para su organización.
    4. Demuestre valor rápidamente y “no aguas abajo” (waterFall)

Los clientes exitosos son lo que siguen el modelo “SnowBall”, es decir partir pequeño e ir aumentando el alcance en el tiempo.

David Chappell

<<Estas son mis notas si Editar, espero poder escribir en forma coherente despúes.>>

1. KEY NOTE "Una vista pragmática"

Tres metas pragmáticas:

•  Estandarizar 
•  Crear los servicios necesarios 
•   Hacer los procesos de negocio

 SOA is a Loosely vision : defines vision.

Ø      Dos aspectos fundamentales.

o       Common protocol.

o       Common foundation

Ø      TCP/IP + WCF son los aspectos fundamentales.

Ø      Framework 3.0:

o       WWF

o       WCF

o       WPF

o       Windows Space?

Ø      .net 2.0 la implementación depende del protocolo.

Ø      .net 3.0 las aplicaciones usan diferente protocolos con una misma API.

Ø      Summary de estandarización de las comunicaciones en SOA

o       Definición de un protocolo común, no es posible. Esto es un problema, que debe ser resuelto.

o       Definición de una fundación (pilares) comunes. WCF

o       Definición de la data. XML, complejo. Se estan usando varias definiciones de los documentos.

o       Getting widesparade adoption, no hay consenso.

o       Providing business value ¿hay valor de negocio? Agilidad y re-uso. Agilidad ok pero re-uso no se está dando mucho. Por ejemplo que pasó con el reuso de objetos, falló.  El reuso de objetos de negocio, .net es reuso de objetos.

o       TCP(/IP soporta todo lo que necesitamos.

2.- SOAP no es suficiente

Ø      QUEUED no soportado.

Ø      Necesita trasformar todos los formatos.

Ø      Se usa para conectar aplicaciones no SAO.

Ø      La realidad es que hay aplicaciones que no hablan SOAP y que tiene una fachada propietaria que tiene interfaz SOAP. En Windows esa fachada está en BizTalk.

3.- ESB?

Ø      ¿Que es eso?

Ø      El problema con ESB es que es lo que llamamos ESB. Las categorías no están claras y son confusas. Depende de la marca que es un ESB.

Ø      Gartner, forester,  tiene una definición. ¿qué significan?

Ø      El punto es que no es posible definirlo hasta ahora.

1.      puntos comunes:

a.       Seguridad

b.      Calidad de servicio.

c.       Registro de servicios y metadata

d.      Extensibilidad de los mensajes

e.       Monitoreo y administración

f.       Soporte al ciclo de vida de los servicios.

4.- El objetivo es crear una infraestructura efectiva de comunicación.

1. BizTalk Server
1. Creando la nueva infraestructura
1. Ø      Fundación: WCF
2. Ø      QUEUED: Biztalk
3. Ø      Data transformación: Mapping de BizTalk
4. Ø      Conexión con diferentes protocolos: BizTalk.
5. Ø      Los otros problemas: Múltiples productos (Willy te quitaron el piso) el futuro será  System center operation manager 2007 (esta hecho WCF)

2.- Use BPM Technologies Effective

Ø      BPM una visión de procesos y eficiencia. Gente de negocio.

Ø      La vista del técnico es crear y ejecutar un proceso lógico.

3.- CORE PBM Technologies

Ø      Workflow (Humanos y maquinas)

Ø      Herramientas gráficas de diseño.

Ø      BRE motor de reglas de negocio

Ø      BAM

Ø      BizTalk: workflow, BRE, BAM (Que casualidad hace todo lo que destacan como importante)

4.- Tecnologías MS para BPM y SOA

Ø      BizTalk 2006

Ø      WCF

Ø      Sharepoint

Ø      WF (Windows Foundation) Foco en gente Developer no para humanos.

Ø      En el futuro la orquestación de BizTalk será para humanos

Ø      Windows Sharepoint Services WSS 3.0.

1.      Tiene capacidad de workflow (versión 2007) viene con témplate y otras cosas que facilitan que humanos hagan y participen en Workflow.

2.      Los usuarios podrán

a.       Usarlo vía Web y Outlook.

3.      Será el HOST de los workflow para humanos

4.      ¿Cómo se crean?

a.       Developer: WF

b.      Humanos: New tools Office Sharepoint Designer 2007.

                                                                                                 i.      La aproximación de esta herramienta es que sea como una serie de reglas, no secuencia de pasos.

ii.      Es una aproximación USer Frendly.

5.      Office Sharepoint Server 2007

a.       Contiene aprobaciones, otras actividades.

b.      Puede usar infoPath

 5.- Conclusiones

Ø      La visión es esencial pero debe ser pragmática

Ø      Tres metas pragmáticas

1.      Estandarización de las comunicaciones.

2.      Cree la infraestructura de servicios necesarias

3.      Use las tecnologías de BPM efectivamente.

Ø      Si usa sigue estas metas, será beneficioso para la organización.

Ø      El reuso es un míto, es un problema de humanos Developer.

Ø      No tiene MS un catalogo de servicios y administración de Metadata “Sorry”.