MSDN Magazine - June 2008 - (Page 48)

The client will also see the Windows CardSpace selector by default, allowing the client to select an identity, which is then sent to BizTalk Identity Services for authentication and authorization. If the client is authorized to send messages to the specified URI, BizTalk Identity Services will return a token indicating that fact, which is then passed to BizTalk Connectivity Services as proof. Having the Windows CardSpace selector appear in this scenario seems pretty acceptable since it’s an interactive client application. Again, you can manage which client identities are allowed to send to a particular URI using BizTalk Identity Services. When BizTalk Connectivity Services receives an incoming message from an authorized sender, it simply relays the message to an instance of SalesService running locally. You shouldn’t really care how it does this because it’s an implementation detail that will very likely change in the future. However, under the covers, RelayBinding uses WCF’s TcpTransport to connect to BizTalk Connectivity Services. When relaying messages, BizTalk Connectivity Services can tunnel through the existing TCP connection back to the local service instance. Why was this so simple? Because BizTalk Connectivity Services takes advantage of standard WCF extensibility points to encapsulate Figure 5 RelayBinding ConnectionMode Options ConnectionMode Value RelayedOneWay Description The connection is set up to accept or send one-way operations only. To use this setting, all methods on your service contract must have an OperationContractAttribute with its IsOneWay property set to true. The connection is set up to support requestreply contracts (including duplex contracts). Same as RelayedDuplex but configured to use WS-ReliableMessaging. Same as RelayedDuplexSession with an optimization. The initial connection between sender and receiver will use BizTalk Connectivity Services, but then it will try to bridge a direct connection between the two nodes if possible. If a direct connection can be made, the sender and receiver will then communicate without BizTalk Connectivity Services in the middle. If a direct connection can’t be made, BizTalk Connectivity Services will continue to provide a relay for communication. The connection is set up to provide publish/ subscribe capabilities. Multiple listeners can register with the same address when using this mode. To use this setting, all methods on your service contract must have an OperationContractAttribute with its IsOneWay property set to true. The connection is set up to expose an HTTP endpoint via BizTalk Services that relays back to a service running on a machine on your local network, even if that service would not normally be accessible through the Internet. the connectivity and relay logic for both the client and the service inside the new RelayBinding. The fact that you can make fundamental communication changes by simply changing the binding (which can be done entirely in configuration) is one of the real advantages of adopting the WCF programming model. Relayed Connectivity Options RelayedDuplex RelayedDuplexSession DirectDuplexSession RelayedMulticast One of the important properties on the RelayBinding object is ConnectionMode. The property’s type is an enum named RelayedConnectionMode. This setting determines how the connection to BizTalk Connectivity Services is made. BizTalk Connectivity Services allows for numerous communication modes between senders and receivers that offer a great deal of flexibility for specific communication scenarios (see Figure 5). RelayedOneWay is meant for one-way messaging scenarios, hence you can only use it with operations marked with IsOneWay=true. RelayedDuplex, on the other hand, is meant for request-reply scenarios including duplex contracts. RelayedDuplexSession is just like RelayedDuplex, but it also enables reliable messaging within the channel stack. This is the default connection mode so it’s the one we actually used in the previous examples. Additionally, the DirectDuplexSession mode is an optimization of RelayedDuplexSession in that it attempts to bridge a direct connection between the sender and receiver if possible. If it cannot, it will fall back to relaying the traffic. We’re going to dive into the last two connection modes in more detail. First, RelayedMulticast enables publish/subscribe over WCF, a communication pattern that isn’t available from any of the builtin WCF bindings. Additionally, RelayedHttp allows you to expose HTTP-based endpoints from within a corporate firewall or behind a NAT, something that developers have struggled with since the advent of Web services. BizTalk Connectivity Services allows multiple listeners to register themselves at a URI when RelayedMulticast is specified by the first listener. Each ServiceHost that has an endpoint listening on that same URI implicitly becomes a subscriber. When a client sends a message to that URI, the message is delivered to all service endpoints currently subscribed. The only real constraint when you use RelayedMulticast is that, like RelayedOneWay, all operations must be marked with IsOneWay=true. Let’s return to our previous sales application. Assume that periodically during the day, we update the price of the different items being sold. We want to broadcast new prices to all salespeople so they are instantly aware. To make this happen, each client application can start a ServiceHost and listen to the same URI using the RelayBinding with ConnectionMode set to RelayMulticast: ServiceHost sh = new ServiceHost(typeof(PriceUpdateService)); sh.AddServiceEndpoint(typeof(IPriceUpdateService), new RelayBinding(RelayConnectionMode.RelayedMulticast), "sb://connect.biztalk.net/services/contososervices/priceupdate"); sh.Open(); RelayedHttp Each client runs this code when the application starts, and thus all client applications will be subscribers to messages sent to sb://connect.biztalk.net/services/contososervices/clientupdate. Each client has now become a subscribing service for purposes of BizTalk Services 48 msdn magazine

Table of Contents Feed for the Digital Edition of MSDN Magazine - June 2008

MSDN Magazine - June 2008 Contents Toolbox CLR Inside Out Cutting Edge Patterns In Practice SAAS Concurrency Robotics Form Filler GUI Library Service Station Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.