MSDN Magazine - June 2008 - (Page 47)

runtime to create the communication layer, known as the channel stack, for sending and receiving messages. The objects in the channel stack perform the network communication, and they determine how security and other protocols are implemented for a particular endpoint. On the listener side, the RelayBinding enables you to expose an endpoint that will be accessible through a global URI supported by BizTalk Connectivity Services. When an endpoint using RelayBinding has been opened, the URI will be registered with BizTalk Connectivity Services and from that point forward any authorized client will be able to send messages to that global URI using a similarly configured client. BizTalk Connectivity Services then becomes the conduit for communication between those two endpoints. ServiceHost sh = new ServiceHost(typeof(SalesService)); sh.AddServiceEndpoint(typeof(ISalesService), new RelayBinding(), "sb://connect.biztalk.net/services/contososervices/SalesService"); sh.Open(); As you can see, in order to expose the service through BizTalk Services, all we have to do is change one line of code—the call to ServiceHost.AddServiceEndpoint. Instead of NetTcpBinding, we use the RelayBinding, which in turn uses BizTalk Connectivity A Typical WCF Application Let’s take a closer look at a simple example. Imagine that we’re a company and we currently expose a WCF service on our internal network that is called from a rich client application. The client application is used by salespeople to process orders. The application calls the service, and then the service initiates the back-end processing necessary to fulfill the order. The service is currently configured with a single endpoint using NetTcpBinding, which enables high-speed connections over TCP/IP. NetTcpBinding is generally the best option for services operating within the firewall. Here’s the code that configures the endpoint and starts the service using the standard ServiceHost: ServiceHost sh = new ServiceHost(typeof(SalesService)); sh.AddServiceEndpoint(typeof(ISalesService), new NetTcpBinding(), "net.tcp://salesservicehost/SalesService"); sh.Open(); One advantage of the WCF programming model is that you can make fundamental communication changes just by changing the binding. Services to expose this endpoint to the world at the specified URI. Messages sent to that address are then relayed to the local SalesService instance. Notice the format of the URI—it begins with the “sb” scheme and is followed by the BizTalk Services host name, which is then followed by “services.” After that, we add the BizTalk Services identity (the account name we’ve set up), in this case it’s contososervices. Then we can add anything we want to the URI in order to make it unique. Here we’ve simply appended SalesService. When you call ServiceHost.Open, the RelayBinding causes WCF to communicate with BizTalk Identity Services in order to authenticate the service identity and to authorize it to listen on the specified URI. The default behavior at this point is for the Windows CardSpace™ selector to appear, asking someone to select a card representing the service’s identity. The fact that a UI appears during authentication is obviously prohibitive for most services since they generally run in headless environments where there isn’t someone logged into the machine. However, we can get around this problem with a little code, which we’ll show you later, so don’t be concerned. For now, we’re just going to select a card that will enable SalesService to begin listening. You can manage which identities are allowed to listen on a particular URI with BizTalk Identity Services. Now let’s look at what it will take to update the client so that it can consume the BizTalk Services endpoint: static void MakeSaleISB(SaleData sd) { string uri = "sb://connect.biztalk.net/services/contososervices/SalesService"; ChannelFactory cf = new ChannelFactory ( new RelayBinding(), new EndpointAddress(uri)); ISalesService service = cf.CreateChannel(); service.EnterSale(sd); } This is standard WCF code. The service implementation is the type SalesService and the contract is ISalesServices. The ServiceEndpoint, created when AddServiceEndpoint is called, uses NetTcpBinding and has an address of net.tcp://salesservicehost/SalesService. Instead of hardcoding the endpoint this way, we could have also configured the endpoint in the application’s configuration file (which is how you’d typically do it). But this sample should be easier to follow by keeping everything in code. Here is a sample client application that then invokes the SalesService to process a sale: static void MakeSale(SaleData sd) { EndpointAddress ea = new EndpointAddress( "net.tcp://salesservicehost/SalesService"); ChannelFactory cf = new ChannelFactory (new NetTcpBinding(), ea); ISalesService service = cf.CreateChannel(); service.EnterSale(sd); } As time goes on, the sales force becomes more mobile, and reports begin coming in that some salespeople aren’t able to connect to process orders when they are out of the office and attached to random networks (some of which don’t allow Virtual Private Network, or VPN, connections). BizTalk Services is able to solve this problem. Let’s see what it takes to expose SalesService via BizTalk Connectivity Services: msdnmagazine.com Notice that the client and service stay exactly the same except for using RelayBinding and specifying the service bus (sb:// ) URI. June 2008 47 http://msdnmagazine.com

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.