SOA Visão Geral das Funcionalidades de Descoberta e Roteamento de Serviços em WCF 4.

SOA Visão Geral das Funcionalidades de Descoberta e Roteamento de Serviços em WCF 4

jorge.goncalves@rumos.pt (MCT) Microsoft Certified Trainer
(MCPD) ASP.NET Developer 3.5 (MCTS) Microsoft Office SharePoint Server 2007 – Configuration Formador Rumos Sys Admin DGITA Consultor Analista Programador PG GSI PG Informática LIC Informática

Module 5: Endpoints and Behaviors
DEMOS Course 10263A Demo : Creating a Calculator Service Demo : Service Routing Demo : Add-hoc Service Discovery Demo : Managed Service Discovery Comunidade Rumos – Webcasts Source Code: MSDN (WCF) Samples 3

Module 1: Service-Oriented Architecture
Course 10263A Why SOA? Challenges in Building Business Applications Objectives of Service-Oriented Architecture What Is a Service? The Pillars of SOA Services Communicate Through Edges

Challenges in Building Business Applications Course 10263A We are living in a distributed world ü This a distributed world. Connectivity is cheap, and it is available almost everywhere. It is a world of diversity. There are many different technologies and frameworks. What was considered impossible in terms of connectivity few years ago is trivial today. It is a common requirement to provide online information and to be in sync with globally distributed data. You are having to build applications that are more complex, yet cost less. Business today is agile. Companies are being sold and merged. New business relations and collaborations are being established every day. All this has an impact on the Information Technology industry. If two companies work together, their IT infrastructure must do the same. Integration is a complex problem, especially when dealing with information systems. The volume of data and operations that applications have to support is increasingly growing. Scalability issues are much more relevant today than they used to be only a few years ago. The average user is more demanding yet less forgiving. Reliability and unavailability problems are not acceptable today. Information security awareness is growing. There are more standards and regulations to follow. Applications are required to collaborate, yet this must be done securely. Applications today deals with complex new challenges. To achieve theses ambitious goals, a new architecture style had to be developed. This is what SOA is all about. Business is agile ü Efficient integration and interoperability are essential ü Costs must be reduced ü Systems have to be scalable, secure, and reliable ü

Objectives of Service-Oriented Architecture Course 10263A SOA is an architectural style designed for building distributed systems ü SOA is an architectural style. Not everything must be designed as a service. SOA was developed to deal with the challenges imposed by the world of high-scale distributed applications. SOA has advantages, but like everything, comes with a price. SOA provides benefits: Agility – applications will adapt quickly to environmental and business changes. Productivity – complex applications will be developed quickly. Reuse – IT services can be cheaper: existing infrastructures and capabilities will be reused across domains. Reduce cost – services are introduced into the system more easily, and more services are reused instead of rewritten. The bottom line: IT services will cost less and provide more. Agility Productivity Reuse Reduce Cost

What Is a Service? Course 10263A SOA is based on Services. What is a service? There is an endless number of definitions of the term “Service”. Services expose functionality – Services do something. To trigger the service’s functionality, a request should be sent. A request is data that is sent to a service. Some services respond immediately and send a response message to the client. A response is data that is sent back to the client. Some services use the “fire and forget” invocation pattern. These services do not send a response back to the client. The client might get some data back from the service at some later point in time. To summarize: Services expose functionality. Data in; Data out. The term “Data” should be emphasized. Data is not technology-specific. Data can be read and written using any technology. This is the core of SOA interoperability and simplicity. A service exposes functionality by accepting data (requests) and sometimes returning data (responses)

The Pillars of SOA Course 10263A The following properties define a service-oriented architecture: ü Services deal with data, not with objects. Objects are dependent on specific technology, whereas data is not technology-specific. Using data means that connectivity is performed on a lower level. It turns out that objects are problematic when dealing with distributed systems. With objects, every simple change breaks the system. In a distributed system, the communicating parties are independent. This means that changes are frequent, and the risk to break the system is high. Communication on the data level has a price. Converting objects to plain data (serialization) is expensive. Compare calling functionality using SOA and using simple method calls (objects). To call a method on an object, all you need to do is put some values on the stack (parameters, return address, etc.) and change the program counter. To call a method on a service, you need to create a message, convert the parameters into plain data, and write it into the message. The message is sent through a transport channel. The service host receives the message, translates is back into objects, creates an instance of the service, and invokes the service method. It is clear that calling functionality on a service is expensive. However, if the functionality is not available locally, then this is the only choice you have got. To enjoy the advantages of SOA, services must be autonomous. When services are autonomous, SOA provides simplicity. The client does not need to know the service’s implementation technology, the exact location of the service, and various other implementation details. The client only cares about the service edge (address) and the information to send. The service can change internally without the consumers knowing about that. Example: Let us think of a bank as a service. We do not know and care about the bank’s data center technology and location. All we know is: Where our banking information can be accessed. (web site, telephone, or the actual branch.) What type of data we need to supply to be able to trigger banking actions. Service boundaries must be explicit. A service has information it is responsible for. All that is inside the service boundaries can be accessed only through the service edge. It must be very clear from inspecting the code that a service is called. Calls to a service must be put inside a try…catch block to handle possible connectivity errors. Services expose contract and policy. As a client, all you care about is the service’s address and the contract to use. The contract defines the data formation to use when calling a service, and the data formation of the response. The service policy defines extra characteristics of the data being sent. For example: Policy can define that the data should be encrypted. Contract = Data shape (what) Policy = Data characteristics (how) Interoperability with the service should be dependent only on the contract and policy. Question: Why is it important for a service to have explicit boundaries? Answer: When a service is used without concern to boundaries, performance can be impaired. For example, if a service is called in a loop many times to add many entities to a database, boundaries are crossed often, and this could have a performance hit on your application. To reduce the number of times the boundary is crossed, you can—for example—create another service operation that receives a bulk of entities, and adds all of them to the database. This way, the boundary is crossed only once instead of numerous times. Understanding the concept of boundaries and implementing it in your service design can improve the way your client and service interact, and improve the overall performance of your system. Services handle data, not objects ü Services are autonomous ü Services have explicit boundaries ü Services expose contract and policy ü

Services Communicate Through Edges Course 10263A Services expose edges to the outside world—edges can be used for communication with the service ü An edge is the access point to the service. Accessing internal assets can be done only through the edge. The edge controls who can access the service, what operations they can perform, etc. Services often expose multiple edges for various reasons (technology, topology, etc.). Real life example: Let us consider the bank as a service. You can access the bank at: The website (address: Technology: HTTP and HTML) The phone (address: phone number; Technology: Public Switched Telephone Network (PSTN)) The ATM on the street (Address: physical address; Technology: WPF (Windows Presentation Foundation)) The branch (Address: physical address; Technology: speak with the person at the desk) Different clients will use different edges to access the bank according to their needs and capabilities. Each edge has an address and technology characteristics (where and how). In Windows Communication Foundation (WCF) terminology, a “service edge” is a “service endpoint”. All interaction with a service is done through an edge ü A service can expose multiple edges ü The edge has an address ü SOA edges are WCF endpoints ü

Demo Creating a Calculator Service
Module 5: Endpoints and Behaviors Course 10263A Demo Creating a Calculator Service The Service ServiceHost Class Endpoint ABC (address binding contract) Metadata behaviour Endpoint behaviour The Client Proxy Pattern 10

Routing The Benefits of Routing
Module 8: Introduction to Advanced Microsoft® Windows Communication Foundation Topics Course 10263A Routing The Benefits of Routing Introduction to the WCF Routing Service Configuring Routing Using Message Filters Configuring Routing Endpoints and Filters Using Custom Filter Types and Content-Based Routing Using Routers for Protocol Bridging Using Routers to Mask Service Unavailability Using Routers for Multicast Messaging 11

The Benefits of Routing
Module 8: Introduction to Advanced Microsoft® Windows Communication Foundation Topics The Benefits of Routing Course 10263A The broker design pattern provides agility and reliability to distributed systems, and enables: ü The broker design pattern is common in distributed systems. It provides agility and reliability. Discussion: Discuss everyday use of the broker pattern: To send a letter, you write the destination address on the envelope, but send the actual letter to the post office. The post office is responsible for locating the recipient and sending the letter. You only need to locate the post office. You can use a routing service to implement advanced messaging topologies. Load balancing is usually done on the transport level. Load balancers do not know the internals of the message. However, sometimes the messages need to be distributed to backend services according to their content. This is impossible with traditional load balancers. Routing services can be used to call a backup service when the original service does not respond, or fails. This masks service unavailability from the clients and improves the system’s reliability. If the service exposes an endpoint in a protocol that cannot be consumed by the client, a routing service can bridge the gap. The client calls the router using a protocol (binding) that is convenient for it, and the router forwards the message using the protocol that is used by the target service. Routers can solve versioning problems, such as breaking contract changes introduced by the service. Question: How can a routing service help to improve the reliability of a service? Answer: By using routing services, you can direct calls made to a failed service to another instance of the service without the client being aware to the failover. This creates the illusion that the service is always available. Content-based load balancing ü Automatically use of fallback services ü Protocol bridging ü Masking of versioning issues ü

Introduction to the WCF Routing Service
Module 8: Introduction to Advanced Microsoft® Windows Communication Foundation Topics Introduction to the WCF Routing Service Course 10263A The Routing Service is part of WCF 4, and is implemented in the System.ServiceModel.Routing.RoutingService class ü WCF 4 introduces a new class: System.ServiceModel.Routing.RoutingService This class is the implementation of a Routing Service. The Routing Service is hosted like any other service in the system (for example, it has a service configuration, and endpoints). The Routing Service uses a special configuration (described later) to configure the routing behavior. The RoutingService class implements the following interfaces: ISimplexDatagramRouter, ISimplexSessionRouter, IRequestReplyRouter, and IDuplexSessionRouter. This enables support for messaging patterns. However, the Routing Service cannot be used to bridge between messaging patterns. To determine the target service to which the message should be forwarded, the Routing Service evaluates each message against a set of message filters (routing rules). When using one-way messaging, the message will be sent to all the services whose corresponding filter returned true. When using request-response messaging, only the first satisfied filter will be used. Hosted like any other service ü Supports all messaging patterns ü Determines the target service by evaluating each incoming message against a set of message filters ü Implements the ISimplexDatagramRouter, ISimplexSessionRouter, IRequestReplyRouter, and IDuplexSessionRouter contracts ü

Configuring Routing Using Message Filters
Module 8: Introduction to Advanced Microsoft® Windows Communication Foundation Topics Configuring Routing Using Message Filters Course 10263A Message filters are specified in code or in the Routing configuration section ü Message filters are routing rules that determine to where the message should be forwarded. Message filters are organized in filters tables. Filter tables can be specified in code, or by using a configuration file. The routing configuration contains a list of filter types and mappings that are based on the filters. A mapping declares an evaluation of a specific filter type on incoming messages, and an endpoint to use if the filter is satisfied. Endpoints are referenced by their name. The endpoint’s details are written in the client configuration section, akin to a standard WCF client configuration. The following example shows how to configure filter tables in code: private void ConfigureRouterInCode(ServiceHost serviceHost) { string routerAddress = " string clientAddress = " Binding routerBinding = new basicHttpBinding(); Binding clientBinding = new basicHttpBinding(); serviceHost.AddServiceEndpoint( typeof(IRequestReplyRouter), routerBinding, routerAddress); ContractDescription contract = ContractDescription.GetContract(typeof(IRequestReplyRouter)); ServiceEndpoint client = new ServiceEndpoint( contract, clientBinding, new EndpointAddress(clientAddress)); //create a new routing behavior RoutingBehavior myRoutingBehavior = new RoutingBehavior(); List<ServiceEndpoint> endpointList = new List<ServiceEndpoint>(); endpointList.Add(client); myRoutingBehavior.FilterTable.Add(new MatchAllMessageFilter(), endpointList); serviceHost.Description.Behaviors.Add(rb); } Message filters are grouped into filter tables ü The routing configuration contains filter types and a collection of mappings between a message filter and a target endpoint ü The RoutingBehavior defines the filter table to use ü

Configuring Routing Endpoints and Filters
Module 8: Introduction to Advanced Microsoft® Windows Communication Foundation Topics Configuring Routing Endpoints and Filters Course 10263A <routing> <filters> <filter name="MatchAllFilter" filterType="MatchAll"/> </filters> <filterTables> <filterTable name="MyFilterTable"> <add filterName="MatchAllFilter" endpointName="Service"/> </filterTable> </filterTables> </routing> <behaviors> <serviceBehaviors> <behavior name="UseRouting"> <routing filterTableName="MyFilterTable" /> </behavior> </serviceBehaviors> </behaviors> <client> <endpoint name="Service“ address="..." binding="...“ contract="..."/> </client> This configuration snippet demonstrates a simple routing configuration. The routing configuration is written inside the routing configuration section. The routing configuration section contains the following sections: Filters. filter types to use. filterTables. a collection of mapping groups. backupLists. a list of endpoints to use when the original service invocation fails (not shown here). namespaceTable. list of namespaces to prefix mappings that can then be used in XPath based filters (not shown here). In this configuration snippet, we use one simple filter of the MatchAll filter type. This filter always returns true—it matches all messages. Every message that will be evaluated against this filter will be forwarded to the endpoint defined at the Service endpoint. This filter table is applied using the UseRouting behavior configuration that contains the routing behavior element.

Using Custom Filter Types and Content-Based Routing
Module 8: Introduction to Advanced Microsoft® Windows Communication Foundation Topics Course 10263A Using Custom Filter Types and Content-Based Routing WCF supports a wide range of filter types ü WCF provides several built-in filter types: Action. Filter according to the message’s action header. EndpointAddress. Filter according to the endpoint address. PrefixEndpointAddress. Filter according to the endpoint address using longest prefix matching. And. Perform a logical and operation between two filters. Custom. Use a user-defined filter. EndpointName. Filter according to the name of the service endpoint. MatchAll. Match all messages. Xpath. Filter using an XPath expression. XPath filters can be used to filter the content of the message. This enables you to implement a content-based routing service. You can create other custom filter types to implement custom routing scenarios. You can use XPath filters to inspect the content of the incoming messages ü You can define custom filters (rules) that target messages according to their content ü You can create custom filter types for advanced routing scenarios ü

Using Routers for Protocol Bridging
Module 8: Introduction to Advanced Microsoft® Windows Communication Foundation Topics Using Routers for Protocol Bridging Course 10263A The client-to-router and router-to-service bindings do not have to match ü It is possible to implement protocol bridging using the Routing Service. The protocol that the client uses to access the router does not have to match the protocol that the router uses to access the target service. The messaging pattern, however, must be consistent across the entire path. For example, if the client uses the request-response pattern, the router should not call the service using one-way messaging. In such a case, the client will throw an exception, because it will not receive the response for which it is waiting. You can bridge incompatible protocols using a Routing Service as the middle-man ü The client-to-router and router-to-service messaging patterns must match ü

Using Routers to Mask Service Unavailability
Module 8: Introduction to Advanced Microsoft® Windows Communication Foundation Topics Using Routers to Mask Service Unavailability Course 10263A You can configure the router service to route a message to a backup service if the target service fails; this masks service unavailability and improves reliability ü You can use backup services to improve system reliability. If the service that was chosen to accept the message fails to receive it, the first endpoint from the backup list will be used (and then the second endpoint, and so on). This configuration snippet a demonstrates the definition of a backup list. If the service defined in the CalcService endpoint fails to accept the message, the AlternateCalc endpoint will be used instead. <routing><filters> <filter name="MatchAllFilter" filterType="MatchAll"/> </filters> <filterTables> <filterTable name="MyFilterTable"> <add filterName="MatchAllFilter" endpointName="CalcService" backupList="AlternateCalc"/> </filterTable> </filterTables> <backupLists> <backupList> <add endpointName="AlternateCalc"/> </backupList> </backupLists></routing>

Using Routers for Multicast Messaging
Module 8: Introduction to Advanced Microsoft® Windows Communication Foundation Topics Using Routers for Multicast Messaging Course 10263A The Routing Service supports multicast, enabling publish/subscribe and distribution-style messaging Multicast means that a message will be forwarded to more then one recipient. Multicast is possible for one-way operations only; the request-response messaging pattern does not allow multicast because only one response is allowed. Multicast is implemented by forwarding a message to all the endpoints whose corresponding filter matched the message. Multicast enables advanced architectural patterns, such as distributing messages to a number of recipients and publish/subscribe loosely-coupled systems. ü If the incoming message matches multiple filters, it will be delivered to each of the target endpoints ü Multicast only works for one-way or duplex messaging; it does not work for request-response messaging ü

WCF Discovery Course 10263A Introduction to WCF Discovery Ad-Hoc Discovery Architecture The Process of Ad-Hoc Discovery Configuring Ad-Hoc Discovery Issuing Probe and Resolve Messages Discovery Proxy Architecture The Process of the Discovery Proxy Discovering Services Using a Discovery Proxy 20

Introduction to WCF Discovery Course 10263A Discovery addresses the question: Where is the service? ü Discussion: Discovery motivation The challenges with service discovery are well known. Service location is dynamic. Server names change. IP addresses and ports mapping change according to various considerations. The client must be able to locate the service. The fact that the service changed its address should be transparent to its clients. Specifying the address in configuration files is impractical. Configuration files are static and managing large configuration files is not easy. A dynamic service repository is part of any Enterprise Service Bus( ESB). An ESB is an integration infrastructure that is responsible for connecting different services that are running on different servers and platforms. A service repository is like a service Yellow Pages, where it is possible to enquire for a service’s location. When a service changes its address, the new address is written to a repository. It is always possible to locate the service. The repository might hold a collection of services from which the client can choose. This allows agility. Services can move, and nothing will break. The client can choose between services at runtime. While ESB is expensive, service location transparency is a common requirement. The WS-Discovery standard was developed to fill this gap. With WS-Discovery, clients can always locate the service. If clients discovers more than one service, they client can choose which one to consume according to various considerations (for example, price). The service’s location is dynamic ü Discovery and Service Repository using WS-Discovery ü Discovery enables agility – choose the service to consume at runtime ü

Ad-Hoc Discovery Architecture Course 10263A WCF 4 introduces WS-Discovery support that consists of two message categories: ü WCF implements WS-Discovery. With WCF 4, it is possible to achieve location transparency without implementing an expensive infrastructure. A service can add a discovery endpoint that listens for discovery messages. A service can add a discovery behavior to enable discovery announcements. WS discovery defines two types of messages: Announcement messages Discovery messages “Hello” and “Bye” announcements are sent by the service when it is opened or closed respectively. “Probe” messages are sent by the client to discover services according to various criteria. The server responds with a “Resolve” message that contains the endpoint details. Announcements (Hello/Bye messages) ü Discovery (Probe/Resolve messages) ü

The Process of Ad-Hoc Discovery Course 10263A Service is up Hello Where is the service? When a service host starts, it sends a “Hello” announcement User Datagram Protocol (UDP) multicast message. Clients listening for announcements will receive such messages, and might decide to consume the service. When a client decides to actively discover a service, it can send a UDP “Probe” multicast message. Services listening for discovery messages might respond. To obtain details about a specific service, the client sends a “Resolve” message. The service will respond with its details. The client can consume a service using the endpoint details that they receive in the “Resolve” message. When the service host closes, it sends a “Bye” announcement UDP multicast message. Clients listening for announcements will receive the “Bye” messages and stop consuming the service. Ad-Hoc discovery and announcements are based on UDP multicasts. This means that Ad-Hoc discovery is limited to the internal subnet, which is the UDP multicast boundary. To allow discovery across the cloud, a you should use discovery proxy. (This will be discussed later in this module.) More information about the discovery protocol can be found at the Introduction to Caching with Windows Server AppFabric (Beta 1) Microsoft website at Probe CLIENT Resolve Bye Service is down Discovery Announcement

Configuring Ad-Hoc Discovery Course 10263A <behavior name="SendAnnouncements"> <serviceDiscovery>  <announcementEndpoints> <endpoint kind="udpAnnouncementEndpoint"/> </announcementEndpoints> </serviceDiscovery> </behavior> The slide shows the three major discovery configuration snippets. ServiceDiscovery behavior. Specifies that the service will issue announcement messages. To specify the endpoint used to send the announcements, use the following element: <endpoint kind="udpAnnouncementEndpoint"/> WCF 4 introduces a new “kind” property to the endpoint configuration section. The “kind” property specifies standard predefined endpoints. Discovery endpoint. One extra endpoint, is added to the service. The endpoint is configured with kind="udpDiscoveryEndpoint“, indicating that it is a discovery endpoint. The service uses this endpoint to receive discovery messages. StandardEndpoints. For further configuration of predefined endpoints, (used with the “kind” property) you can use the StandardEndpoints configuration section. <service name=“...” behaviorConfiguration="SendAnnouncements"> . . .  <endpoint name="udpDiscovery" kind="udpDiscoveryEndpoint“ endpointConfiguration="adhocDiscoveryEndpointConfiguration"/> </service> <standardEndpoints> <udpDiscoveryEndpoint>  <standardEndpoint name="adhocDiscoveryEndpointConfiguration“ discoveryVersion="WSDiscovery11" maxResponseDelay="00:00:00.600" /> </udpDiscoveryEndpoint> </standardEndpoints>

Issuing Probe and Resolve Messages Course 10263A The DynamicEndpoint class is used by the client to issue probe messages ü A typical client uses the DynamicEndpoint class to issue discovery “Probe” messages, and to resolve the service’s address. The dynamic endpoint includes a FindCriteria instance that defines the services to be discovered. The following code demonstrate how to use the FindCriteria class explicitly: DynamicEndpoint dynamicEndpoint = new DynamicEndpoint( ContractDescription.GetContract(typeof(ICalculatorService)), new NetTcpBinding()); Uri redmondScope = new Uri("net.tcp://Microsoft.Samples.Discovery/RedmondLocation"); Uri seattleScope = new Uri("net.tcp://Microsoft.Samples.Discovery/SeattleLocation"); Uri portlandScope = new Uri("net.tcp://Microsoft.Samples.Discovery/PortlandLocation"); dynamicEndpoint.FindCriteria.Scopes.Add(redmondScope); dynamicEndpoint.FindCriteria.Scopes.Add(seattleScope); dynamicEndpoint.FindCriteria.Scopes.Add(portlandScope); The following configuration fragment demonstrates how to configure a dynamic endpoint in the XML configuration file and how it is used in code: <client>  <endpoint name="calculatorEndpoint" binding="wsHttpBinding" contract="ICalculatorService" kind ="dynamicEndpoint" endpointConfiguration="dynamicEndpointConfiguration"> </endpoint> </client> <dynamicEndpoint> <standardEndpoint name="dynamicEndpointConfiguration"> <discoveryClientSettings>  <endpoint kind="udpDiscoveryEndpoint" endpointConfiguration="adhocDiscoveryEndpointConfiguration" /> Dynamic endpoints can be defined in code and in the XML configuration file ü The FindCriteria class enables granular discovery ü // Discover endpoints when the client is opened. // The contract is used as the FindCriteria. // UdpDiscoveryEndpoint is used to send Probe message. DynamicEndpoint dynamicEndpoint = new DynamicEndpoint( ContractDescription.GetContract( typeof(ICalculatorService)), new WSHttpBinding());

Demo Add-hoc Service Discovery
Module 5: Endpoints and Behaviors Course 10263A Demo Add-hoc Service Discovery The Service behaviourConfiguration for serviceDiscovery announcementEndpoints for announcements Enpoint with kind=“udpDiscoveryEndpoint” for discovery Calc endpointBehaviorConfiguration behaviour for scope criteria The Client Endpoint with kind=“dynamicEndpoint” and dynamicEndpointConfiguration for find scope criteria 27

Discovery Proxy Architecture Course 10263A The discovery proxy enables discovery support outside the enterprise: ü A discovery proxy listens for announcements inside the subnet boundaries. It exposes a well-defined endpoint to the outside world. Services on the outside issue discovery queries to the proxy. The proxy can answer according to its internal cache, or forward a ″Probe ″ message inside the subnet and respond with the ″Resolve ″ message. The discovery proxy acts like a simple service repository. You can also implement routing and load balancing. Question: Is it possible to use discovery outside of the local subnet boundaries? Answer: No. discovery announcements and Probe/Resolve messages uses the UDP transport, which cannot be used outside the local subnet boundary. To use discovery outside the subnet—for example on the Internet—use a discovery proxy. Listens for announcements and caches endpoint information internally ü Forwards “Probe” and “Resolve” messages ü Can function as a router ü

The Process of the Discovery Proxy Course 10263A Service is up Hello Where is the service? The discovery proxy resides within the subnet, between the service and the client. The client sends probe messages to the proxy. The proxy sends a multicast message probe inside the subnet. The proxy resolves the service address, and the endpoint details are sent back to the client. PROXY CLIENT Probe Resolve Bye Service is down Subnet Discovery Announcement

Discovering Services Using a Discovery Proxy Course 10263A The DiscoveryClient class calls the discovery proxy; it can also be used to issue “Probe” messages inside the subnet ü To use a discovery proxy, clients use the DiscoveryClient class. The discovery client is configured with the discovery proxy endpoint address and binding. When calling the Find method, the process of sending a “Probe” message through the proxy begins. The result is received as a collection of endpoint details that are wrapped inside a FindResponse object. The following code demonstrates how to use a discovery client to issue “Probe” messages inside the subnet using the UdpDiscoveryEndpoint. DiscoveryClient discoveryClient = new DiscoveryClient(new UdpDiscoveryEndpoint()); // Find ICalculatorService endpoints in the specified scope Uri scope = new Uri("ldap:///ou=engineering,o=exampleorg,c=us"); FindCriteria findCriteria = new FindCriteria(typeof(ICalculatorService)); findCriteria.Scopes.Add(scope); findCriteria.MaxResults = 1; FindResponse findResponse = discoveryClient.Find(findCriteria); // The discovery endpoint points to the discovery proxy Uri probeEndpointAddress = new Uri("net.tcp://localhost:8001/Probe"); DiscoveryEndpoint discoveryEP = new DiscoveryEndpoint( new NetTcpBinding(), new EndpointAddress(probeEndpointAddress)); // Call the discovery proxy DiscoveryClient discoveryClient = new DiscoveryClient(discoveryEP); FindResponse findResponse = discoveryClient.Find( new FindCriteria(typeof(ICalculatorService))); if (findResponse.Endpoints.Count > 0) InvokeCalculatorService(findResponse.Endpoints[0]. Address);

Using Routers for Multicast Messaging
Module 8: Introduction to Advanced Microsoft® Windows Communication Foundation Topics Using Routers for Multicast Messaging Course 10263A The Routing Service supports multicast, enabling publish/subscribe and distribution-style messaging ü Multicast means that a message will be forwarded to more then one recipient. Multicast is possible for one-way operations only; the request-response messaging pattern does not allow multicast because only one response is allowed. Multicast is implemented by forwarding a message to all the endpoints whose corresponding filter matched the message. Multicast enables advanced architectural patterns, such as distributing messages to a number of recipients and publish/subscribe loosely-coupled systems. If the incoming message matches multiple filters, it will be delivered to each of the target endpoints ü Multicast only works for one-way or duplex messaging; it does not work for request-response messaging ü

Demo 2.2 Managed Service Discovery
Module 5: Endpoints and Behaviors Course 10263A Demo 2.2 Managed Service Discovery The Discovery Proxy Abstract Class The Service Announces it’s presence in the proxy’s anouncement endpoint The Client Endpoint with kind=“dynamicEndpoint” And dynamicEndpointConfiguration for find scope criteria set it’s discovery address endpoint to the proxy’s probe address 32

SOA Visão Geral das Funcionalidades de Descoberta e Roteamento de Serviços em WCF 4.

Similar presentations

Presentation on theme: "SOA Visão Geral das Funcionalidades de Descoberta e Roteamento de Serviços em WCF 4."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

SOA Visão Geral das Funcionalidades de Descoberta e Roteamento de Serviços em WCF 4.

Similar presentations

Presentation on theme: "SOA Visão Geral das Funcionalidades de Descoberta e Roteamento de Serviços em WCF 4."— Presentation transcript:

Similar presentations

About project

Feedback