Hernan de Lahitte Software Architect

Presentación del tema: "Hernan de Lahitte Software Architect"— Transcripción de la presentación:

1 Hernan de Lahitte Software Architect hernan@lagash.com
(D3) Como programar la integración de aplicaciones utilizando Microsoft Business Integrator 3.0 En esta sesión se mostraran casos prácticos acerca de como utilizar la nueva versión de MBI la cual esta basada íntegramente en la arquitectura propuesta por el grupo de PAG de Microsoft Corp. llamada EDRA (Enterprise Development Reference Architecture) también conocida por su nombre clave "Shadowfax". Veremos las características principales que introduce esta versión, asi como también las nuevas posibilidades que ofrece la fusión con el modelo de EDRA. Hernan de Lahitte Software Architect

2 Agenda Introducción a MBI Introducción a Shadowfax
Arquitectura de MBI 3.0 Implementación de Aplicaciones Roadmap e Iniciativa

3 Audiencia Arquitectos Lead Developers Arquitectos y Desarrolladores
Estandarizar el desarrollo de aplicaciones distribuidas Lead Developers Customizar la solución para reunir los requerimientos de una organización Arquitectos y Desarrolladores Solución a problemas particulares The Enterprise Development Reference Architecture targets three distinct audiences. The first target audience includes architects and lead developers who want to standardize development of distributed applications. For this audience, the reference architecture includes an evaluation process that leads the architect or developer through fit analysis, initial evaluation, in-depth evaluation, and adoption. It includes complete source code for the application framework to support this evaluation. After an architect or lead developer decides to use the application framework, he or she may want to customize the solution to meet the requirements of a specific organization and create binaries for application developers to use. Application developers are the second target audience. Developers can use the binary implementation of the framework as the basis for development, allowing them to focus on solving business problems. The final target audience consists of architects and developers interested in solving particular challenges (for example, call interception, instrumentation, exception shielding, and so on). These people can obtain reuse of designs from the architecture documentation, or simply cut and paste code from the application framework.

4 Agenda Introducción a MBI Introducción a Shadowfax
Arquitectura de MBI 3.0 Implementación de Aplicaciones Roadmap

5 ¿Porque MBI? Construir soluciones corporativas es una tarea compleja:
Escasa Visión Integrada de Arquitectura IT Excesiva problemática técnica por resolver Aplicaciones de misión crítica Seguridad y calidad son factores claves Integración de aplicaciones Necesidad de integrar diferentes canales Necesidad de desarrollar soluciones de negocio más rápido Las organizaciones han aumentado considerablemente su dependencia con los sistemas automatizados de manejo de la información haciendo que la complejidad y alcance de los mismos se haya incrementado notablemente. Esto ha impuesto grandes desafíos tanto a los grupos de desarrollo, como a los de operación y mantenimiento. Estos desafíos han sido no sólo en el aspecto técnico puro sino también en la organización y estructura de recursos humanos. A esto se le suma la necesidad imperiosa de disminuir costos sin detrimento de la calidad de lo que se produce. Actualmente Microsoft ha publicado guías de arquitectura como SOA (Service Oriented Architecture). La arquitectura basada en componentes (component-based architecture) resolvió el problema del código integrado definiendo capas de funcionalidad. Una aplicación quedaba así definida en 3 capas: capa de acceso a datos (Data Access) , capa de lógica de negocios (Business Logic) y por último la capa de presentación. Sin embargo, en el ambiente moderno de aplicaciones distribuidas resulta complicado con este tipo de arquitectura compartir componentes entre distintas aplicaciones que hayan sido desarrollados en diferentes lenguajes y distintas plataformas. A raíz de este problema se desarrolló la arquitectura orientada a servicios conocida como SOA. En vez de pensar en procesos pensamos en servicios, y cada uno de estos tiene una interfaz que brinda un punto de acceso para cualquier proceso que requiera la lógica de negocio del mismo. Los proveedores de servicios y las aplicaciones clientes que los consumen se comunican por mensajes, generalmente se utilizan documentos XML lo cual provee toda la funcionalidad, granuladidad y escalabilidad requerida por el sistema de mesajes. Con este modelo se logra: Un modelo para organizar recursos de IT dado que los recursos se acceden a través de un sistema de mensajes. Un modelos de componentes mejorado (complemento de la programación orientada a objetos) Propuestas de valor: encapsular complejidad, integración e interoperabilidad, maximización de la reutilización, ciclo de mejora continua, reducción del tiempo de desarrollo y reducción del tiempo de mantenimiento.

6 ¿Qué es MBI? MBI es un framework para crear, ejecutar y mantener aplicaciones corporativas basadas en la plataforma Microsoft .NET Resuelve escenarios recurrentes de una empresa corporativa Es una arquitectura de referencia para la construcción de aplicaciones Incorpora mejores prácticas de Microsoft Corporation Arquitectura de integración común a todos los Portfolios de Soluciones Reducción de costos de desarrollo y mantenimiento Microsoft Business Integrator es un framework desarrollado por la práctica de consultoría de Microsoft Argentina (MCS) en base a la experiencia recogida por su participación en diversos proyectos de desarrollo e integración de aplicaciones de negocio y su profundo conocimiento de la tecnología y las herramientas de Microsoft Corporation. Su objetivo principal es proveer un marco integrado que facilite la creación y administración de aplicaciones corporativas y de misión crítica utilizando herramientas y tecnologías provistas por Microsoft Corporation y basadas en un modelo de procesamiento distribuído. El modelo Microsoft Business Integrator profundiza el modelo propuesto por SOA, a través de una arquitectura mucho más detallada, prescriptiva y refinada, basada en la experiencia que ha acumulado Microsoft a través de sus servicios de consultoría y soporte (MCS y PSS). El objetivo, al igual que SOA es proveer una plataforma tecnológica robusta, confiable, económica y ágil. Este Marco Tecnológico abarca todos los componentes de los sistemas de información, sean estos técnicos u organizacionales y logra sus objetivos con las siguientes estrategias: Basado en EDRA: Primeramente conocido como Shadowfax es el nombre clave para "Enterprise Development Reference Architecture" (EDRA) que esta orientado a simplificar el desarrollo de aplicaciones distribuidas, proveyendo una serie de pautas estandarizadas de uso común en soluciones orientadas a proveer servicios de negocios. Profundizando el modelo de aplicación: - Proveyendo una fuerte separación en la capa de presentación de la lógica de navegación y el formateo de pantallas. - Facilitando el tratamiento de entidades persistentes en múltiples fuentes de datos y en aplicaciones externas. - Incluyendo soporte explícito para aspectos de integración de aplicaciones y de manejo del procesos de negocio. Construyendo una arquitectura técnica común: - Alineado al modelo. - Otorgando una solución común a problemas técnicos recurrentes. Transacciones, parametrización, usuarios, etc. - Proveyendo soporte nativo para la integración de aplicaciones. - Abstrayendo la plataforma técnica subyacente. Implementando un marco de trabajo: - Conjunto de herramientas y procesos que faciliten la construcción y administración de aplicaciones compatibles con la arquitectura propuesta. Es importante destacar que los niveles de productividad de un grupo de tecnología no están sólo focalizados en el desarrollo. Comúnmente cuando se plantea el problema de la productividad se piensa en el desarrollo, es por eso es que tradicionalmente se hace hincapié en aumentar la productividad a través de la reutilización de componentes (por ejemplificar un caso). Sin embargo los componentes no son las únicas piezas que una organización puede reutilizar. Los procesos, las herramientas, las buenas prácticas o incluso las cosas menos obvias también pueden ser reutilizados contribuyendo a la productividad total de la organización. Algunos ejemplos de elementos reutilizables, pero menos evidentes, son los planes de trabajo o templates de pruebas. Es por esto que MBI pretende ser una propuesta integral, que se extienda más allá de ser un conjunto de reglas y normativas de programación.

7 ¿Qué es MBI? – Escenarios
MBI brinda soluciones en estos escenarios: OLTP Aplicaciones multicanal Ruteo on-line de transacciones Aplicaciones orientadas a tareas Enterprise Application Integration (EAI)* Consistencia de Datos (publicación / suscripción) Automatización de Procesos de Negocio Aplicaciones Compuestas / Agregación Para poder describir los escenarios que MBI resuelve, es necesario entender que EDRA es un framework generico, el cual no tiene limitaciones de implementación y además nunca fue pensado para resolver un escenario sino poder amoldarce a cualquiera. Pero MBI al ser un framework prescriptivo necesita acotarce a escenarios concretos. MBI fue concebido para facilitar la creación de soluciones de negocio en los siguientes escenarios: Procesamiento de Transacciones en Línea (OLTP). Esto es un sistema de datos diseñado para grabar todas las transacciones de negocios de una organización mientras estas se van desarrollando. Entre estas podemos destacar: - Aplicaciones Multicanal. - Ruteo on-line de transacciones. - Aplicaciones orientadas a tareas. Integración de Aplicaciones: - Consistencia de Datos (publicación / suscripción). - Automatización de Procesos de Negocios. - Aplicaciones Compuestas / Agregación. * Definición del Gartner Group

8 Agenda Introducción a MBI Introducción a Shadowfax
Arquitectura de MBI 3.0 Implementación de Aplicaciones Roadmap

9 ¿Qué es Shadowfax? Es una Guía de Arquitectura para estandarizar el desarrollo de sistemas distribuidos Es un Framework de Aplicaciones Extensible el cual incorpora recursos de la plataforma; ASP.NET-WS, MSMQ, Enterprise Services, Remoting, WSE Es una Implementación de Referencia que usa el Framework en un modelo bancario Es una iniciativa (PAG) apoyada en un fuerte feedback de la comunidad y la industria EDRA=Shadowfax The EDRA uses four guiding principles to help ease the transition from tightly coupled distributed objects to standards-based, loosely coupled services: ● Separating the service interface from the internal service implementation to allow for deployment scenarios that are optimized for scalability, reliability, security, performance, and availability. ● Separating business logic from cross-cutting concerns such as logging, monitoring, or raising business events. (A cross-cutting concern is a type of functionality that can be applied to multiple classes or applications.) ● Separating business logic from the underlying transport so that multiple transports can be used to access a single service implementation. ● Developing stable service interfaces to ensure resiliency of deployed services. Microsoft developed the SDRA after talking with customers and reviewing solutions that were developed to solve similar problems on both the Microsoft® .NET and J2EE platforms. The SDRA provides the following: ● Architectural guidance describing how to address the preceding four principles. ● An extensible application framework that incorporates reusable assets to facilitate development of distributed applications using ASP.NET Web services, Microsoft Windows® operating system Message Queuing, Enterprise Services, and, in the future, Web Service Enhancements (WSE) and Indigo. ● Four QuickStart applications that demonstrate key capabilities of the framework. ● An application template to help you set up a development environment to implement services and build client applications that use the services.

10 Visión de Shadowfax Percibir los beneficios de SOA con .NET sin experimentar grandes complicaciones en su implementación EDRA se basa en percibir los beneficios de SOA con .NET sin experimentar grandes complicaciones en su implementación. Para esto crea un Framework SOA basado en las experiencias de socios y clientes lideres que provee acceso multi-canal a los servicios, incorpora bloques y guias existentes. Dada su arquitectura es altamente extensible y adaptable y crea además una implementación de referencia. And that is just what the Shadowfax project is all about. If you want to implement SOA with .NET, Shadowfax will provide a framework which Takes the best ideas from the many SOA frameworks Encourages a style which “future proofs” (as much as possible) your application Is implemented according to the existing patterns & practices guidance Our vision is that with Shadowfax, you will be able to quickly realize the SOA benefits without having to endure the pain of a trial and error implementation.

11 Estrategia de Shadowfax
Crear un Framework pensando en SOA Basado en las experiencias de socios y clientes lideres Proveerá acceso multi-canal a los servicios Incorporará bloques y guías existentes Altamente extensible y adaptable (source code) Crear una implementación de referencia Basada en problemática recurrente en sistemas distribuidos de grandes clientes EDRA se basa en percibir los beneficios de SOA con .NET sin experimentar grandes complicaciones en su implementación. Para esto crea un Framework SOA basado en las experiencias de socios y clientes lideres que provee acceso multi-canal a los servicios, incorpora bloques y guias existentes. Dada su arquitectura es altamente extensible y adaptable y crea además una implementación de referencia. And that is just what the Shadowfax project is all about. If you want to implement SOA with .NET, Shadowfax will provide a framework which Takes the best ideas from the many SOA frameworks Encourages a style which “future proofs” (as much as possible) your application Is implemented according to the existing patterns & practices guidance Our vision is that with Shadowfax, you will be able to quickly realize the SOA benefits without having to endure the pain of a trial and error implementation.

12 Modelo Conceptual Todo se reduce a esta simple interacción pero…
Problemas a Resolver Entrega del mensaje Cross Boundaries Manejo de Errores Soporte de Transacciones The conceptual view identifies, at a high level, the interaction of architectural elements. As a project artifact, it serves to identify the project vision based on previously identified business and user requirements. For the Enterprise Development Application Framework, this vision defines a loosely coupled, service-based architecture. The interaction between a client application and the service (or business action) it invokes can be simplified as a request and a response. Within the EDAF, the business action refers to the requested service and excludes everything but the actual business logic. In other words, it is the component that performs the business logic requested by the client application. There is more involved in this process than simply sending a request to a business action and waiting for the response. For example: ● How will the message be delivered? ● Is the request sent across process boundaries or server boundaries? ● How will errors be handled? ● Will transactions be supported? El desafío es lograr que todo siga siendo asi de simple pero en un modelo SOA

13 Modelo Orientado a Servicios
Interface Data SQL Pipes and Filters Implementation Biz Operation Invocation Separa la interfase del servicio de sus detalles de implementación Separa la lógica de negocios de la lógica de procesamiento transversal Separa la lógica de negocios del transporte subyacente The EDRA uses four guiding principles to help ease the transition from tightly coupled distributed objects to standards-based, loosely coupled services: ● Separating the service interface from the internal service implementation to allow for deployment scenarios that are optimized for scalability, reliability, security, performance, and availability. ● Separating business logic from cross-cutting concerns such as logging, monitoring, or raising business events. (A cross-cutting concern is a type of functionality that can be applied to multiple classes or applications.) ● Separating business logic from the underlying transport so that multiple transports can be used to access a single service implementation. ● Developing stable service interfaces to ensure resiliency of deployed services. If you spoke with the Shadowfax architects, this is what they would tell you. Let’s take this apart and think about it point by point. Uniform approach for exposing business services Wouldn’t it be great if you could expose your service to many different types of clients by speaking their language and accepting a message from them using the technology stack that they speak. Or would it? We are at the phase where we must question everything so here is the question to you. How important is it to you that your service can be accessed over multiple channels? If it is important, which channels do you require? Declarative approach to processing service requests This simply means that you should be able to declare by service some basic infrastructure that you require and will enable via meta-data. Provide business event notification You need to be able to fire events to tell people and other systems what is happening Simplify workflow integration This simply means that we will show you exactly how workflow fits into this architecture Support security and manageability of the architecture We will provide tools and integration points where you can apply security and management control Assure performance and scalability We will test this in our lab to insure that the framework supports highly scalable systems Make the architecture elegant and minimal In the end, it has to be simple and lightweight. Whew! Sounds like a tall order!

14 Uso de Patterns & Practices
Patrones Dominantes Service Interface Delegator (variante del Interceptor) Chain of Responsibility (Pipelines) Applications Blocks utilizados Data Access Configuration Management Logging Authorization & Profiling An important goal in developing the Enterprise Development Application Framework and the Reference Implementation was to demonstrate usage of patterns & practices guidance including: ● patterns & practices and industry standard design patterns such as service interface, service implementation, model view controller, and pipeline. ● patterns & practices application blocks, including: ● Authorization and Profile Application Block ● Configuration Management Application Block for .NET ● Data Access Application Block for .NET ● Logging Application Block ● Guidance from patterns & practices books on designing secure, scalable, and performant applications including: ● Improving Web Application Security: Threats and Countermeasures, Microsoft Press®, ISBN: ● Building Secure ASP.Net Applications: Authentication, Authorization and Secure Communication, Microsoft Press, ISBN: ● Improving .NET Application Performance and Scalability, Microsoft Press, ISBN:

15 Service Interface & Delegator
Three patterns have dominated the architecture of the framework: ● The Service Interface pattern, as described in Enterprise Solution Patterns Using Microsoft .NET, Redmond: Microsoft Press®, 2003 ● A variant of the Interceptor pattern called the Delegator pattern, as described in Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects, by Douglas Schmidt et al., Chichester, England: John Wiley & Sons, 2000 ● The Chain of Responsibility pattern, as described in Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma et al., Reading, Massachusetts: Addison Wesley Longman, Inc., 1995 The Service Interface pattern decouples service interface mechanisms from the service implementation, so that they can vary independently. In the framework, the service implementation is represented by business action objects. Business action objects are invoked by the service implementation elements of the framework and serve as entry points to service business logic. Service interface elements perform boundary functions for the service. They receive service requests from clients, dispatch those requests to service implementation elements, and return results to clients. The framework provides multiple mechanisms to allow independent evolution of the service interface and the service implementation. It also allows for multiple ways of hosting and deploying service interface and service implementation elements, either together or separately. The Delegator pattern provides a request interception mechanism that allows cross-cutting logic to be inserted into the request processing flow. The interceptor takes the form of two pipelines as shown in the Figure. The primary reason for using two distinct pipelines is to enable deployment scenarios where they are on separate computers for reasons such as security or reliability. The cross-cutting logic is included in the pipelines as handler objects. The same pipeline class (type) is used for all service interface transports. Each time a service request message arrives, an interface transport adapter places the message into a common envelope object (the Context object), and passes it to a pipeline instance. The pipeline instance uses configuration data supplied by the adapter to identify: ● The handlers to be invoked on the inbound service request message. ● The pipeline target to be invoked when the request reaches the end of the pipeline. ● The handlers to be invoked when the service response message is returned. As described above, the framework has separate pipelines for the Service Interface and Service Implementation layers. The Service Interface pipeline is transport-specific (it is used for Web services, Message Queuing, or .NET Remoting), and focuses on service boundary handlers. Service boundary handlers usually perform initial checks and validations, such as authentication, request monitoring, and message request validation. The target of this pipeline is the dispatching target, which is responsible for invoking the second pipeline in the service implementation. This approach is known as a Bridge pattern. (For more information about dispatching targets, see "Service Request Flow" in this section.) The pipeline in the Service Implementation layer (the implementation pipeline) is service-specific and focuses on service-specific behavior. Handlers in this pipeline are usually related to and focused on business actions. These handlers raise business events, log service requests, or manage transactions. The target of an implementation pipeline is responsible for invoking a business action. A business action is the entry point into the implementation of the requested service. It is either a business component, or it calls your business component(s). In either case, this is the ultimate target of the original service request. A business action is executed and, in most cases, produces a response.

16 Cadena de Responsabilidad
Un pipeline articula la ejecución de la cadena de handlers y el target como end point de la cadena The Chain of Responsibility pattern is used to guide the design pipelines. In the framework, pipelines assemble handlers in a chain of responsibility, as shown in the figure. The pipeline constructor uses configuration data to stack handler objects in such a way that the pipeline calls the first handler, and each subsequent handler calls the next handler. The last element in the chain is the pipeline target, which reverses the process, returning control to the last handler, which then returns control to the handler that called it, and so on. This design allows handlers to act on requests and on the responses that are returned. Not all handlers take advantage of this feature. Handlers that process both requests and responses are referred to as around handlers. Handlers that handle only requests or responses are referred to as atomic handlers. Una tubería (pipeline) es una popular arquitectura que conecta componentes computacionales (filtros) a través de conectores (pipes), de modo que las computaciones se ejecutan a la manera de un flujo. Los datos se transportan a través de las tuberías entre los filtros, transformando gradualmente las entradas en salidas. […] Debido a su simplicidad y su facilidad para captar una funcionalidad, es una arquitectura mascota cada vez que se trata de demostrar ideas sobre la formalización del espacio de diseño arquitectónico, igual que el tipo de datos stack lo fue en las especificaciones algebraicas o en los tipos de datos abstractos.

17 Separación de Funcionalidades
En la siguiente figura se muestra como la interface del servicio (Service Interface) esta separada de la implementación del mismo (Service Implementation) y la funcionalidad típica (Cross-Cutting Logic) de la lógica de negocios Development of loosely coupled services requires attention to both the external service interface and the internal service implementation. When developing a service interface, developers must ensure that the service interface is stable and that few dependencies exist between the sender and the receiver. Design of the service implementation is also critical because any systems that consume deployed services are highly dependent on a service's availability. Techniques such as transactions, durable queues, and redundant deployment are commonly used to ensure system integrity. The Enterprise Development Application Framework introduces a layered software architecture that helps meet the objectives identified in the "Overview." Figure 1 demonstrates how a service interface is separated from service implementation and how cross-cutting logic is separated from business logic. The EDAF can be used in its original form or tailored to meet your specific needs. Consider this example: Suppose you are assigned the task of developing an online portal for a bank's customers. The online portal includes new banking products such as automatic bill subscription and payment. When developing the new business capabilities, you need to use a consistent design and ensure that deployed services can be monitored and audited in a standard manner. You also need to ensure that business logic does not become obsolete; therefore, you need to separate it from the underlying transport. You can use the EDAF to ensure consistent design and implementation of the service interface, service business logic, and cross-cutting logic. The EDAF supports separation of the service interface from the service implementation, allowing for: ● Resiliency of the service interface so that the underlying service implementation can be changed over time. ● Optimized deployment patterns for security, scalability, and performance. A single, consistent method of handling service requests, regardless of the transport on which they arrived. Many heterogeneous environments require multiple transports. ● A transport independent means of specifying cross-cutting logic declaratively. Cross-cutting logic, such as monitoring, security, or logging, can be inserted into service request processing to keep this logic separate from the service business logic. This is supported by two configurable pipelines. ● A simple mechanism to integrate service requests with service orchestration and workflow. Workflow automates business processes that logically encapsulate a rich business component with possibly complex orchestration.

18 Built-in Handlers Seguridad Instrumentación y Logging Mensaje
Autenticación (Windows, DB, Custom, DS) Autorización (DB, Custom) Instrumentación y Logging Publicación de Eventos Instrumentación (Perf.Counters) Client Trace (Monitoreo) Mensaje Detección de Mensajes Duplicados Transformación Validación sintáctica Infraestructura Manejo de Timeouts de Requests Soporte de Transacciones Atomicas y Compensadas (Long Running) The Enterprise Development Application Framework provides out of the box service request handlers that can generate business events consumable by Microsoft BizTalk® Server. The framework also incorporates handler implementations that can be declaratively configured to address cross-cutting concerns, including: ● Authentication. The framework can support Windows authentication as well as custom authentication. ● Authorization. Handlers facilitate Windows authorization as well as custom authorization. ● Event publishing. Handlers support publication of asynchronous notifications. ● Duplicate message detection. Handlers provide support for idempotent messaging. ● Request timeout management. The framework provides a standard means of enforcing timeouts across transports. ● Atomic and compensating transaction support. Transactions ensure consistency and integrity of data. As you explore the EDAF, keep in mind that it provides a great deal of functionality. The source code for this framework is provided. If you choose to, you can modify this code to suit your particular needs, or you may decide to use the code as-is and focus on solving business problems. Either way, you will benefit from learning and working with the framework.

19 Escenario de Deployment
Aplicaciones Cliente Red Perimetral Red Interna Service Interface Svr Internet Service Impl. Svr. The EDAF architecture was designed to be flexible when deployed. Therefore, it provides a number of different options. The basic configuration consists of two servers, with the externally accessible server sitting between two firewalls in the perimeter network (also known as the DMZ). In this figure, the first server is referred to as the Service Interface server, and it rests within the perimeter network. This would be the physical location of the Service Interface layer. The second server sits securely behind the second firewall, along with the configuration database. This would be the home of the Service Implementation layer. Client applications running on desktops, laptops, or external servers make requests across a transport. The request goes through the first firewall, to the service interface server. The server receives the request (invoking the pipeline). The request continues through the second firewall to the service implementation server, which ultimately invokes the business action. Dispositivos Móviles Sistemas Corporativos

20 Agenda Introducción a MBI Introducción a Shadowfax
Arquitectura de MBI 3.0 Implementación de Aplicaciones Roadmap

21 MBI 3.0 & Shadowfax Definición
Implementación prescriptiva de Shadowfax Revisada por el equipo de PAG de Microsoft Corp. MBI 3.0 complementa a Shadowfax en escenarios que Shadowfax aún no resuelve MBI 3.0 implementa como componente central a Shadowfax MBI & Shadowfax proveen el contexto adecuado para la construcción de aplicaciones orientadas a servicios

22 MBI 3.0 & Shadowfax Beneficios adoptados
Código de base mejorado (80% Refactoring) Mayor esfuerzo en horas de pruebas Modelo más flexible y extensible (white box) Integración con los Application Blocks corporativos (EIF, CMAB, Etc.) Maximización del uso de la plataforma Decisiones de diseño pensadas en compatibilidad y tendencias a futuro MBI 3.0 & Enterprise Development Reference Architecture (EDRA) El modelo SOA propuesto por MBI es una alternativa de implemetación de EDRA revisada por el equipo de PAG de Microsoft Corp. Utilizando este modelo se adoptan los siguientes beneficios: Menos código que mantener Código de base mejorado Mayor esfuerzo en horas de testing Modelo más flexible y extensible Incorporación de nuevas funcionalidades (EIF, CMAB, etc.) Maximización del uso de la plataforma

23 MBI 3.0 y ademas … Compatibilidad 100% con MBI 2.x
Interfaces, binarios, soporte side by side de versiones Confiabilidad y Performance Hosting IIS/ASP.NET Health Monitoring Aislación entre aplicaciones (AppDomains) Seguridad IIS/Sfx Handlers/Configs/etc. Mantenimiento y Operación Actualización de configs y assemblies on-the-fly Monitoreo (WMI) y Debugging (Tracers) Desarrollo Nuevas Tools y Wizards Esta implementación consiste en la creación de una serie de handlers, targets y la definición de varios pipelines. El esquema muestra los pipelines definidos mostrando El objetivo principal de MBI 3.0 es proveer todas las funcionalidades de su antecesor (MBI a la que nos referiremos como MBI2 en el resto del documento), siendo implementado como una aplicación SOA sobre Shadowfax. La configuración de MBI define las apliaciones y las acciones a proveer, exactamente de la misma manera que en MBI2, es decir, se mantiene total compatibilidad con el esquema anterior de configuración. Por otro lado, la configuración de Shadowfax es la que define los pipelines, cómo se componen y los mecanismos de invocación posibles entre ellos, además de opciones extra para cada componente. MBI corre como un web service, es decir que está hosteado en IIS/ASP.NET, lo que provee varios beneficios: Seguridad. IIS autentica los llamados de los clientes. Además provee SSL. Es el único host (frente a un windows service o custom application) que provee un canal seguro de comunicación. Escalabilidad. Se puede crear un web-farm con varios servidores con una configuración NLB (network load balancing). Performance. Hay dos implementaciones del CLR de .Net y su mecanismo de garbage collector. Una de ellas está diseñada para computadoras con un solo procesador, conocida como Workstation GC (Mscorwks.dll). La otra implementación, conocida como Server GC, está diseñada para soportar computadoras multiprocesadores (Mscorsvr.dll). y es la utilizada por ASP.NET en servidores multiprocesadores. Server GC está optimizado para maximizar el rendimiento y la escalabilidad. Adicionalmente al utilizar este modelo de hosting se puede hacer uso de sus capacidades de SHM (System Health Monitoring) simplificando el modelo implementado en MBI2 (ver System Health Monitor (SHM) para mayor detalle)

24 Diseño sobre Shadowfax
Interface Transport: Web Service (ex Dispatcher) Hosting en IIS Refactoring en Targets y Handlers Auth/Authz handlers Command, Providers, Transacciones, Timeout AppDomainTarget (aislacion entre aplicaciones) ActionTarget (Ejecución de Business Actions) Conectores y Procesos Externos MSMQ transport (acople débil con el core system)

25 Implementation Pipeline
Arquitectura MBI 3.0 IIS Web Service (Default AppDomain) Auth Command StandIns Authz ApDmTarget Interface Pipeline ExecuteAction ExecuteBatch Implementation Pipeline Application Domain Timeout Hooks Transactions OutputProvs ActionTarget Acciones Acciones Acciones

26 Equipos de Desarrollo Equipo de Web UI
Enfocado sólo en la capa de presentación Piensa en enviar y recibir mensajes Pasa requerimientos al equipo de servicios Equipo de Servicios Enfocado sólo en la capa de servicios Piensa en recibir y devolver mensajes No diseñan en una “burbuja” (Interop)

27 Equipos de Desarrollo Tensión Equipo de Web UI En su “burbuja”
Desean una respuesta rápida Desean un fácil acceso a los datos Equipo de Servicios Piensa a largo plazo Construye servicios autónomos No confía en nadie (Seguridad)

28 Agenda Introducción a MBI Introducción a Shadowfax
Arquitectura de MBI 3.0 Implementación de Aplicaciones Roadmap

29 Aplicación Task Tarea Task Tarea Pipelines Pipelines Sistemas Externos
Application Una colección de tareas que interactúen con múltiples servicios. Interacción entre tareas y servicios y servicios con servicios externos es a través del intercambio de mensajes.

30 Servicios Servicios Entity Business Action Sistemas Externos
Punto de interacción entre una tarea y los aplicativos. Punto de contacto público (interfase). Una acción tiene una pólitica: Seguridad Control de acceso Validaciones de negocio Interacción con el propio de la app. como con dominios públicos (backend) La capa de servicio agregan valor de negocio mas allá de actuar como Gateways a sistemas de backend. TransferFunds GetBalances PayBill Customer Account PaymentOrder

31 Modelos de Invocación Interfaz centrada en Command Pattern
Interfaz centrada en el Mensaje [WebServiceInterfaceAdapter] [WebMethod] MessageResponse ExecuteAction(MessageRequest req) { } [WebMethod] MyActionResponse MyAction(MyActionRequest req) { DispWebMethod dwm = new DispWebMethod(); … } Interfaz centrada en Command Pattern Pros Encourages encapsulating internal state Encourages message-based communication (far model) Cons More time-consuming to develop Interfaz centrada en el Mensaje Expose a single service which accepts many kinds of messages Easier to secure a single URL Dynamic command routing

32 Modelo de Aplicación con MBI 3.0

33 Agenda Introducción a MBI Introducción a Shadowfax
Arquitectura de MBI 3.0 Implementación de Aplicaciones Roadmap

34 MBI 3.0 & Shadowfax Evolución de MBI como Framework para Arquitectura de Aplicaciones Corporativas 2002 2003 2004 2005 MBI 1.X MBI 2.X MBI 1.X surge en función de los requerimientos funcionales y experiencias en implementaciones de proyectos por parte de MCS Argentina. MBI 2.X surge en función de solicitud de mejoras de nuestros clientes & partners. Dichas modificaciones son realizadas por MCS Argentina. El arquitecto de MBI forma parte del equipo de SFX. Nutre a SFX de las experiencias obtenidas en implementaciones de MBI y de comentarios de nuestros clientes & partners. SFX surge como producto de las funcionalidades soportadas por MBI y otros frameworks desarrollados por otras prácticas de MS en el mundo. MBI 3.0 surge a efectos de proteger la inversión de los clientes & partners que implementaron MBI. Surge como la implementación de SFX que consideramos mas apropiada para nuestros clientes & partners (revisada y avalada por PAG). Evoluciona junto a estándares corporativos. En fecha de Longhorn la arquitectura evolucionará en el marco de Indigo (Microsoft Framework basado en .NET, para construir y ejecutar sistemas distribuidos e interconectados. Shadowfax MBI 3.0 (Powered by Shadowfax)

35 Resumen MBI 3.0 Mejor implementación sobre Shadowfax
Con un ojo puesto en las tecnologías emergentes y tendencias del mercado Permite una evolución gradual entre ambas Arq. Complementa con servicios propios de MBI Alineado con las guías y documentos de PAG Full Compatible con MBI 2.x Interfaces, Binarios, Configuración Experiencia simple de migración y deployment

36 MBI 3.0 – Iniciativa Recursos Lista de distribución
Workspace en GotDotNet Versión de MBI actual: Beta 1 de MBI 3.0 disponible en octubre Información:

37 Shadowfax Info GotDotNet Workspace
Wiki Patterns & Practices Weblog Hofmeister, Christine, Robert Nord, and Dilip Soni. Applied Software Architecture. Reading Massachusetts: Addison-Wesley, 1999 Enterprise Solution Patterns Using Microsoft .NET, Redmond: Microsoft Press, 2003, ISBN: Also available on MSDN at Douglas Schmidt et al. Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects Chichester, England: John Wiley & Sons, 2000 Erich Gamma et al. Design Patterns: Elements of Reusable Object-Oriented Software, Reading, Massachusetts: Addison Wesley Longman, Inc., 1995 Building Secure Microsoft ASP.NET Applications: Authentication, Authorization, and Secure Communication, Redmond: Microsoft Press, 2003, ISBN: Also available on MSDN at Improving Web Application Security: Threats and Countermeasures, Redmond: Microsoft Press, 2003, ISBN: Also available on MSDN at

38 Preguntas

39