AZURE .NET SERVICES SERVICE BUS in C#.NET

Make Data Matrix 2d barcode in C#.NET AZURE .NET SERVICES SERVICE BUS

services. In other words, the services are provided by service applications run behind the firewall, and the connection endpoints are provided by .NET Service Bus. The reason .NET Service Bus makes communication easier is that all its clients now see only an IP address provided by it instead of one directly exposed by organizations. It also improves service access security because it is designed to collaborate with .NET Service Access Control, which applies user-defined rules to ensure security when an application claims tokens via the STS service provided by .NET Service Access Control. In practice, an application that intends to expose its service via .NET Service Bus implements the services based upon WCF, but it does not have to. As long as the calling application can make the request via SOAP or REST, there is no restriction for which technology the target application uses to implement the service interfaces.

Figure 6-1. .NET Service Bus concept The core and essential part of .NET Service Bus uses globally addressable Internet access based on REST or SOAP. All endpoints, resources, and applications provide a URI for access. The Internet services provided by .NET Service Bus cover the following three major categories: Service name hierarchy system Service registry and publishing Endpoint relay connectivity

.NET Service Bus is built upon WCF. All interactions with the application are URI-addressable. The URI address uses a hierarchical structure. In principle this name hierarchy system in .NET Service Bus is a forest and can go infinitely deep. There is no need for applications to explicitly perform name system housekeeping. The name system is a virtual logic system. When an application s registration is deleted or removed from the system, all names under that application are automatically deleted. .NET Service Bus maintains the name system based upon the Azure solution created from the cloud. In other words, the Azure solution name is the first level in the URI hierarchy structure. It is an application s call how to organize its name hierarchy system starting from the application root (the registered solution name from Azure), as long as the solution s name makes sense to the application. An application associated with .NET Service Bus can have multiple instances. The solution name is to allow .NET Service Bus to manage and distinguish the applications. On the client or user side, there is no limit to how many applications can be registered or how many instances can be associated to an application.

The service registry is where we publish service endpoint references to the .NET Service Bus name system by sending an HTTP PUT request; we send an HTTP DELETE request to remove the registration from the name system. We can discover a service by traversing the name hierarchy tree.

The core part of .NET Service Bus is the relay service that supports connection-oriented bidirectional communication. Relay services listen for HTTP requests from the cloud instead of from a local source. The connection usually starts with a listener, either local or remote. To establish the bidirectional communication, the approach is to simply pair up two connections and reverse the listener and sender roles. The advantage of using relay services is obvious. An application can use the relay service as a filter to block the traffic it is not interested in and hides all detailed information about network locations to reduce security threats. The relay services can also provide access control to request application authentication before establishing the connection.

The key difference between a standard WCF binding and its counterpart relay binding is where the service establishes the listener. The standard WCF application establishes the listeners locally, whereas the relay binding does so from the cloud. .NET Service Bus allows applications to connect across platforms since it is based on open Internet standards. Those applications using the WCF communication framework to switch to .NET Service Bus services just need to modify the configuration file to change the regular WCF binding types to relay binding types. For example, the WebHttpBinding has a corresponding WebHttpRelayBinding, the BasicHttpBinding has a corresponding BasicHttpRelayBinding, and so forth. The significant difference after switching to the relay service is that the application is listening for the HTTP request from the cloud instead of locally. All relay connections must connect to the .NET Service Bus. That is the essential difference between using relay connections and regular WCF connections. The .NET Service Bus also supports all regular WCF features, such as reliable message delivery, message security, and transport security. However, the