![SOA en la Práctica: Windows Communication Foundation y Web Service Software Factory Julio Casal Software Developer John Galt Solutions [email_address] http:// msguayaquil.com / blogs / jcasal](https://image.slidesharecdn.com/soaenlaprcticawcfwssf-12876346495514-phpapp01/85/SOA-en-la-Practica-WCF-amp-WSSF-1-320.jpg)
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (18)
Ähnlich wie SOA en la Práctica: WCF & WSSF
Ähnlich wie SOA en la Práctica: WCF & WSSF (20)
Mehr von juliocasal
Mehr von juliocasal (8)
Kürzlich hochgeladen
Kürzlich hochgeladen (11)
SOA en la Práctica: WCF & WSSF
- 1. SOA en la Práctica: Windows Communication Foundation y Web Service Software Factory Julio Casal Software Developer John Galt Solutions [email_address] http:// msguayaquil.com / blogs / jcasal
- 3. Arquitectura Orientada a Servicios
- 4. La Imperativa de Conectar EMPLEADOS MÓVILES CLIENTES EMPLEADOS MÓVILES CLIENTES
- 8. Cuatro Principios Clave de la Orientación a Servicios Los servicios y los consumidores son versionados, puestos en producción, operados y asegurados independientemente. Los Servicios son autónomos Los datos nunca incluyen comportamiento; Los objetos con datos y comportamiento son un fenómeno local. Compartir esquema y contrato, no clase Las capacidades y requerimientos son representados por un nombre público único; Usados para definir si un servicio es apropiado. Compatibilidad basada en política Los desarrolladores se concentran en consumir, exponer y definir fachadas de servicios expuestas al público. Los límites son explícitos
- 12. Lo Que Escuchamos del Desarrollador “ ¿Qué API debería usar?” “ ¿Cómo debo construir sistemas orientados a servicios?” “ ¿Cómo puedo enviar mensajes de forma segura y confiable?” “ ¿Cómo puedo desarrollar aplicaciones interoperables?”
- 13. El framework unificado de aplicaciones orientadas a servicios para construcción rápida Windows Communication Foundation
- 15. Productividad: WCF Modelo de Programación Unificado Interop with other platforms ASMX Attribute- Based Programming Enterprise Services WS-* Protocol Support WSE Message- Oriented Programming System.Messaging Extensibility Location transparency .NET Remoting
- 17. Soporte al Protocolo WS-*
- 20. Comunicación de Servicios Cliente Servicio Servicio 1 Servicio 2 Mensaje Mensaje
- 21. Endpoints Cliente Servicio Mensaje Endpoint Endpoint Endpoint
- 22. Address, Binding, Contract Cliente Servicio Mensaje Address Binding Contract (Dónde) (Cómo) (Qué) A B C A B C A B C
- 23. Metadata Cliente Servicio Mensaje Metadata A B C A B C A B C
- 24. Behaviors Cliente Servicio Mensaje Bv Bv Bv Bv Metadata A B C A B C A B C
- 25. Runtime Cliente Servicio Mensaje Metadata Bv Bv Bv Bv Proxy ServiceHost<T>() A B C A B C A B C
- 26. ¿Cómo afecta WCF a mi código? Binding Address Contract
- 27. ¡Hola Mundo WCF!
- 28. Web Service Software Factory
- 32. La Visión de Microsoft Software Factory Implementaciones de Referencia Narrador Blocks How Tos Hand On Labs Documentación Paquetes de Guías Presentaciones, Videos Página de Lanzamiento Comunidad
- 34. Implementando una arquitectura orientada a servicios
- 36. Recursos .NET Framework 3.0 y el Windows SDK http://msdn.microsoft.com/windowsvista/downloads/products/getthebeta/ Web Service Software Factory http:// www.gotdotnet.com/codegallery/codegallery.aspx?id =6fde9247-53a8-4879-853d-500cd2d97a83 Blogs http://wcf.netfx3.com/roller/default.aspx Laboratorios Virtuales http:// msdn.microsoft.com/virtuallabs/wcf/default.aspx Sitios Web http://wcf.netfx3.com http://msdn.microsoft.com/winfx/technologies/communication/default.aspx http:// www.msguayaquil.com Libros Microsoft Windows Communication Foundation: Hands-on http://www.samspublishing.com/bookstore/product.asp?isbn=0672328771&rl=1 Programming Indigo http://www.amazon.com/gp/product/0735621519/104-1500335-4931949?v=glance&n=283155 Videos, Presentaciones, Laboratorios y Webcasts http://wcf.netfx3.com/content/resources.aspx
Hinweis der Redaktion
- Necesitamos comunicarnos con otros negocios Construir sistemas distribuidos para soportar estos escenarios es muy difícil: Negocios socios (partner) requieren interoperabilidad Empleados necesitan seguridad Familias no les importa la seguridad, sino más bien rendimiento Nada de esto tiene que ver con lógica de negocios ->aquí entra WCF
- In recent years, the software industry has seen a resurgence of service-oriented application development. Excitement around service orientation (SO) and service-oriented architecture (SOA) has been nothing less than infectious – permeating all facets of IT society, from the analyst community and press to software vendors and corporations. Business executives describe “achieving SOA” as though it were a Zen-like state of corporate bliss; industry influentials debate the intricacies that distinguish SOA from Event-Driven Architecture (EDA) and other SOA-related acronyms; and software vendors vie for SOA mindshare through newly repositioned software and service offerings. At the same time, the industry buzz around SO is rivaled only by the incongruence with which different analysts, vendors, and corporations define the term. Service orientation, at its most fundamental level, is a set of best practices for building distributed applications – software that communicates with other software. Microsoft’s philosophy on SO differs from other vendors in its simplicity of definition, its target audience, and its scope of importance. These are described below. Service Orientation is not new Much of the recent hype around SO is based on its perceived novelty as a new paradigm for magically refining IT infrastructure. Yet the earliest references to service-orientation date back to the late 1970s1. SO is based on the enduring challenge to build software that evolves over time to reflect the ever-changing needs of the business. It is a natural evolution from the object-oriented and component-based application development trends of the past several decades, preordained by a number of recent economic and technological factors. What is new about service orientation is developers’ ability to more easily build service-oriented applications – a change catalyzed by the broad acceptance of Web services. SOA is not focused on the BDM While the merits of developing applications using a service-oriented approach are hard to deny, they should be communicated to the appropriate audience. Like object orientation and component-based development, SO is a methodology for building software and as such should be messaged to developers and architects. Service orientation is predicated on developers’ ability to build loosely coupled systems that adhere to four core design principles: service boundaries are explicit; services share contracts and schema; services use message-based communication for interaction; services are autonomous and managed independently; and services use policy assertions to control the behavior. While BDMs certainly receive the indirect benefits of a well-architected infrastructure built on service-oriented principles, their interest in the internal design decisions of IT projects should be that of other equally geeky endeavors – negligible at best. SOA is not the end goal It is merely a means to an end. The end goal for businesses is an integrated value chain that drives profits, minimizes IT costs, and provides IT flexibility to adapt with the needs of the business. Only Microsoft’s Connected Systems combines a robust software foundation, architectural guidance, and an ever-growing partner ecosystem to connect information workers with vital information, connect applications with the IT infrastructure, and connect the needs of the business with those of IT.
- The acronym SOA prompts an obvious question – what, exactly, is a service? Simply put, a service is a program that can be interacted with via well-defined message exchanges. Services must be designed for both availability and stability. Services are built to last while service configurations and aggregations are built for change. Agility is often promoted as one of the biggest benefits of SOA – an organization with business processes implemented on a loosely-coupled infrastructure is much more open to change than an organization constrained underlying monolithic applications that require weeks to implement the smallest change. Loosely-coupled systems result in loosely-coupled business processes, since the business processes are no longer constrained by the limitations of the underlying infrastructure. Services and their associated interfaces must remain stable, enabling them to be re-configured or re-aggregated to meet the ever-changing needs of business. Services remain stable by relying upon standards-based interfaces and well-defined messages – in other words, SOAP and XML schemas for message definition. Services designed to perform simple, granular functions with limited knowledge of how messages are passed to or retrieved from it are much more likely to be reused within a larger SOA infrastructure. As stated earlier, recalling basic OO design principles regarding encapsulation and interface design will serve us well as we design and build reusable Web Services. We can extend these OO principles into the world of Web Services by further understanding four frequently cited “tenets” of Service Orientation (see next slide)
- 1. Boundaries are explicit A service-oriented application often consists of services that are spread over large geographical distances, multiple trust authorities, and distinct execution environments. The cost of traversing these various boundaries is nontrivial in terms of complexity and performance. Service-oriented designs acknowledge these costs by putting a premium on boundary crossings. Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message passing rather than implicit method invocation. Compared to distributed objects, the service-oriented model views cross-service method invocation as a private implementation technique, not as a primitive construct—the fact that a given interaction may be implemented as a method call is a private implementation detail that is not visible outside the service boundary. Though service-orientation does not impose the RPC-style notion of a network-wide call stack, it can support a strong notion of causality. It is common for messages to explicitly indicate which chain(s) of messages a particular message belongs to. This indication is useful for message correlation and for implementing several common concurrency models. The notion that boundaries are explicit applies not only to inter-service communication but also to inter-developer communication. Even in scenarios in which all services are deployed in a single location, it is commonplace for the developers of each service to be spread across geographical, cultural, and/or organizational boundaries. Each of these boundaries increases the cost of communication between developers. Service orientation adapts to this model by reducing the number and complexity of abstractions that must be shared across service boundaries. By keeping the surface area of a service as small as possible, the interaction and communication between development organizations is reduced. One theme that is consistent in service-oriented designs is that simplicity and generality aren't a luxury but rather a critical survival skill. 2. Services are autonomous Service-orientation mirrors the real world in that it does not assume the presence of an omniscient or omnipotent oracle that has awareness and control over all parts of a running system. This notion of service autonomy appears in several facets of development, the most obvious place being the area of deployment and versioning. Object-oriented programs tend to be deployed as a unit. Despite the Herculean efforts made in the 1990s to enable classes to be independently deployed, the discipline required to enable object-oriented interaction with a component proved to be impractical for most development organizations. When coupled with the complexities of versioning object-oriented interfaces, many organizations have become extremely conservative in how they roll out object-oriented code. The popularity of the XCOPY deployment and private assemblies capabilities of the .NET Framework is indicative of this trend. Service-oriented development departs from object-orientation by assuming that atomic deployment of an application is the exception, not the rule. While individual services are almost always deployed atomically, the aggregate deployment state of the overall system/application rarely stands still. It is common for an individual service to be deployed long before any consuming applications are even developed, let alone deployed into the wild. Amazon.com is one example of this build-it-and-they-will-come philosophy. There was no way the developers at Amazon could have known the multitude of ways their service would be used to build interesting and novel applications. It is common for the topology of a service-oriented application to evolve over time, sometimes without direct intervention from an administrator or developer. The degree to which new services may be introduced into a service-oriented system depends on both the complexity of the service interaction and the ubiquity of services that interact in a common way. Service-orientation encourages a model that increases ubiquity by reducing the complexity of service interactions. As service-specific assumptions leak into the public facade of a service, fewer services can reasonably mimic that facade and stand in as a reasonable substitute. The notion of autonomous services also impacts the way failures are handled. Objects are deployed to run in the same execution context as the consuming application. Service-oriented designs assume that this situation is the exception, not the rule. For that reason, services expect that the consuming application can fail without notice and often without any notification. To maintain system integrity, service-oriented designs use a variety of techniques to deal with partial failure modes. Techniques such as transactions, durable queues, and redundant deployment and failover are quite common in a service-oriented system. Because many services are deployed to function over public networks (such as the Internet), service-oriented development assumes not only that incoming message data may be malformed but also that it may have been transmitted for malicious purposes. Service-oriented architectures protect themselves by placing the burden of proof on all message senders by requiring applications to prove that all required rights and privileges have been granted. Consistent with the notion of service autonomy, service-oriented architectures invariably rely on administratively managed trust relationships in order to avoid per-service authentication mechanisms common in classic Web applications. 3. Services share schema and contract, not class Object-oriented programming encourages developers to create new abstractions in the form of classes. Most modern development environments not only make it trivial to define new classes, modern IDEs do a better job guiding you through the development process as the number of classes increases (as features like IntelliSense® provide a more specific list of options for a given scenario). Classes are convenient abstractions as they share both structure and behavior in a single named unit. Service-oriented development has no such construct. Rather, services interact based solely on schemas (for structures) and contracts (for behaviors). Every service advertises a contract that describes the structure of messages it can send and/or receive as well as some degree of ordering constraints over those messages. This strict separation between structure and behavior vastly simplifies deployment, as distributed object concepts such as marshal-by-value require a common execution and security environment which is in direct conflict with the goals of autonomous computing. Services do not deal in types or classes per se; rather, only with machine readable and verifiable descriptions of the legal &quot;ins and outs&quot; the service supports. The emphasis on machine verifiability and validation is important given the inherently distributed nature of how a service-oriented application is developed and deployed. Unlike a traditional class library, a service must be exceedingly careful about validating the input data that arrives in each message. Basing the architecture on machine-validatible schema and contract gives both developers and infrastructure the hints they need to protect the integrity of an individual service as well as the overall application as a whole. Because the contract and schema for a given service are visible over broad ranges of both space and time, service-orientation requires that contracts and schema remain stable over time. In the general case, it is impossible to propagate changes in schema and/or contract to all parties who have ever encountered a service. For that reason, the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces. It is common for services to use features such as XML element wildcards (like xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code. 4. Service is determined based on policy Object-oriented designs often confuse structural compatibility with semantic compatibility. Service-orientation deals with these two axes separately. Structural compatibility is based on contract and schema and can be validated (if not enforced) by machine-based techniques (such as packet-sniffing, validating firewalls). Semantic compatibility is based on explicit statements of capabilities and requirements in the form of policy. Every service advertises its capabilities and requirements in the form of a machine-readable policy expression. Policy expressions indicate which conditions and guarantees (called assertions) must hold true to enable the normal operation of the service. Policy assertions are identified by a stable and globally unique name whose meaning is consistent in time and space no matter which service the assertion is applied to. Policy assertions may also have parameters that qualify the exact interpretation of the assertion. Individual policy assertions are opaque to the system at large, which enables implementations to apply simple propositional logic to determine service compatibility.
- Pregunta 1: para que el sistema dure y se adecúe durante años
- Indigo es una extensión al .NET Framework 2.0 Ayuda a que las aplicaciones les hablen a otras aplicaciones Es un set de clases que puedes usar cuando estás construyendo aplicaciones para hacer el “trabajo sucio” que hay que hacer al construír aplicaciones distrubuidas hoy en día
- Productividad: Escribir menos código Interoperabilidad Tanto con otras plataformas como con otros sistemas
- No se necesita saber más de un modelo de programación
- WS es una organización de estándares sobre web services que especifica funcionalidades avanzadas de servicios web
- ES = Enterprise Services Upgrade incremental
- Cliente inicia la comunicación con el servicio Mensaje Ej: Agrega este item a mi carrito de compras
- Endpoint es similar a una interfaz en OO No expone los detalles de la implementación del servicio El Endpoint nos dice todo lo que necesitemos saber para comunicarnos con el servicio Cliente y servicio son desacoplados, es decir, el cliente no depende de los cambios a la implementación del servicio Cliente crea un proxy endipoint y hace llamadas locales a ese proxy. El proxy se encarga de toda la comunicación con el endpoint en el lado del servicio Pueden haber múltiples Endpoints, para así tener por ejemplo múltiples mecanismos de comunicación con un mismo servicio, uno interoperable, otro de alto rendimiento, etc
- Metadata: incluye lo que se necesite para hacer uso del endpoint en el servicio (Ej: Adress, contract, )
- Behaviors: Determinan cómo se comporta el servicio Ejemplo: una sola instancia en el servicio?, cuánta concurrencia?
- El servicio se puede alojar en varios host, consola, IIS, win service, win app, utilizando ServiceHost ServiceHost genera todo el Metadata automáticamente El caller descarga el Metadata y genera el proxy
- Address: Es donde vive el servicio (Ej: http://localhost/miservicio) Binding: Es cómo te comunicas con el servicio. Ej: Qué transporte usar? http, tcp, named pipes? Que codificador usar? Xml, binary, personalizado Usarás seguridad? De qué tipo? Contract: Qué información recibirá y enviará el servicio, qué operaciones realizará