Client Server Integration - Case Study Example

1. Support for distributed application development a. .NET Remoting .NET Remoting is a technology that allows developers to create widely distributedapplications, capable of accessing .NET components on remote machines. This technology is highly flexible and customizable as it provides an abstract approach to inter-process communication in order to eliminate the need of specific communication method and specific client or server application domain for remotable objects (Microsoft Corporation, 2010a). .NET Remoting has a modular and extensible architecture which is composed of basic building blocks on the host side and the client side. The basic building blocks on the host side are transport channels, formatters, and call dispatchers, while on the client side, the basic building blocks are proxies, formatters, and transport channels (Löwy, 2003). Figure 1: .NET Remoting Architecture (Löwy, 2003) Client Side Processing The client interacts with the remote object through the proxy. The proxy is responsible to enable the client to make a method call or access a property on it, and then to marshal that call to the actual remote object. A remote object can be accessed by multiple proxies; however, a single proxy can be bound to one object at most. The client side involves the following steps (Löwy, 2003): Step 1: The client makes a call on the proxy. Step 2: The proxy takes the parameters to the call (the stack frame), and creates a message object. Step 3: The formatter serializes the message object, and passes it to the channel object which moves the message object to the remote object. While the above steps are in progress, the proxy blocks client and waits for the call to return. When the call returns from the channel, the formatter deserializes and forwards the returned message to the proxy, which then places the output parameters and the returned value on the client’s call stack, and finally returns control to the client (Löwy, 2003). Server (Host) Side Processing As mentioned by Löwy (2003), the server side processing consists of the following steps: Step 4: The server-side channel receives the message object, and forwards it to a formatter. Step 5: The formatter deserializes the message, and passes it to the stack builder. Step 6: The stack builder reads the method and its parameter in the message, and then calls an appropriate object. When the call returns to the stack builder, it forwards a reply message to the server-side formatter which then serializes the message, and passes it to the channel object for the delivery to the client. Appropriate use of .NET Remoting .NET Remoting is ideal for implementing solutions to perform customized message exchange with other applications; for example, implementing a custom networking protocol or data encoding mechanism (Turner, 2005). .NET Remoting also provides the fastest mechanism to allow objects in different app domains within the same Windows process to call one another, therefore, it is ideal for applications that make a large number of calls between components residing in different app domains within the same process in shortest possible time (Turner, 2005). It is important to note that .NET Remoting is a tightly coupled technology which intends to support only .NET Remoting-to-.NET Remoting communication. Due to this reason, .NET Remoting is not suitable for applications which seek broad interoperability (Turner, 2005). b. Microsoft Message Queuing (MSMQ) Microsoft Message Queuing technology allows applications to communicate across heterogeneous networks and systems that may be temporarily offline. MSMQ provides efficient routing, guaranteed message delivery, priority-based messaging and security, and therefore, can be used effectively to implement synchronous and asynchronous solutions requiring high performance (Microsoft Corporation, 2010b). Figure 2: Basic working of MSMQ (Microsoft Corporation, 2010b) The MSMQ architecture helps administrators to manage thousands of computers by creating logical groups of computers running MSMQ. The architecture is based on a Site/Enterprise model in which a site represents a group of computers at some physical location, and an enterprise represents an organization consisting of one or more sites. All the computers in an organization that are running MSMQ forms a logical group, called MSMQ Enterprise (Redkar et al., 2004). All the information about the MSMQ Enterprise is maintained by the Directory Service. The Directory Service stores every property for the machines and public queues that form part of the organization; however, it is important to note that it does not store messages. The Directory Service also maintains security credentials which are used by the MSMQ Service for routing purposes. The distributed Directory Service database is stored at every MSMQ server machine. The implementation of the Directory Service depends on the version of MSMQ. MSMQ 1.0 uses the MSMQ Information Store (MQIS) which is implemented through a SQL Server database. On the other hand, MSMQ 2.0 and higher implements the Directory Service through Active Directory (Redkar et al., 2004). Appropriate use of MSMQ MSMQ is primarily used for queued messaging. It is a mature and powerful technology that provides buffered, asynchronous, bi-directional communications infrastructure. .NET framework contains System.Messaging (SM) namespace that allows developers to create applications that benefit from the powerful features in MSMQ (Turner, 2005). Nowadays, most of the developers tend to use MSMQ because they feel more secure about the future of their applications as MSMQ is a valuable part of the Microsoft future distributed technology stack, and Microsoft is currently making significant investments in MSMQ to provide a much-improved release in Windows “Longhorn” (Turner, 2005). 3. Utilizing Grid computing. Grid computing is a way of combining different computing resources – such as, processing cycles, memory, disk spaces, networks, printers, scanners, remote devices etc. – in a manner so that they all act as a single unit. Grid computing provides fast and cheap processing for computationally intensive tasks by splitting the complex computation task into sub-tasks (jobs) that could be processed in parallel using available computing resources. Examples of grid computing applications are drugs discovery, economic forecasting, disasters forecasting, climate prediction, data processing, graphics and videos rendering, and complex mathematical problems (Riad, Hassan, & Hassan, 2010). Windows Communication Foundation (WCF), formerly known as Indigo, is the technology offered by .NET Framework 3.0 and higher that enables service-oriented applications and systems on machines running Windows operating system. WCF implements SOAP (Simple Object Access Protocol) and WS-* specifications to allow interoperability and communication between interacting nodes (Riad, Hassan, & Hassan, 2010). A grid computing system can use WCF services to overcome limitations of traditional XML Web Services. In grid computing system, management server is usually responsible for preparing tasks, checking returned result sets, and packaging and offering final results to original senders. As shown in Figure 3, the system exposes a number of services that act as interfaces to management server, and each service is exposed with a number of different endpoints to meet different needs, such as different security settings, transport protocols, serialization techniques, and encoding options (Riad, Hassan, & Hassan, 2010). Figure 3: Proposed Architecture (Riad, Hassan, & Hassan, 2010) As shown in above figure, the three main endpoints are: NetTcpBinding: This is the fastest system-provided bindings offered by WCF which is suitable for homogenous (.NET to .NET) communication over LANs – means this option is less interoperable. This option uses TCP as a communication protocol and binary serialization for data being transmitted between clients and servers (Riad, Hassan, & Hassan, 2010). BasicHttpBinding: This option provides access to the traditional Web Services (ASMX services in .NET) endpoints. This option uses a plain-text messages and UTF-8 encoding by default, and therefore, this binding is slower than NetTcpBinding. However, this option can be configured to use more efficient data formats, such as binary or Message-Transmission Optimization Mechanism (MTOM) methods. BasicHttpBinding endpoints are interoperable due to its conformance with WS-I Basic Profile 1.1, and therefore, it allows external clients (both homogenous and heterogeneous) to access grid resources in easy and flexible manner (Riad, Hassan, & Hassan, 2010). WSHttpBinding: Similar to BasicHttpBinding, this binding uses HTTP transport and WS-* specifications; however, it has more advanced features, such as support for federation, distributed transactions, and secure and reliable communication sessions. This binding is ideal for Internet users to guarantee security and reliability (Riad, Hassan, & Hassan, 2010). References Löwy, J. (2003). Programming .NET components. Sebastopol, California: OReilly Media, Inc. Microsoft Corporation. (2010a). .NET Remoting Overview. Retrieved June 7, 2010, from .NET Remoting Overview: http://msdn.microsoft.com/en-us/library/kwdt6w2k(VS.71).aspx Microsoft Corporation. (2010b). Message Queuing (MSMQ). Retrieved June 7, 2010, from Message Queuing (MSMQ): http://msdn.microsoft.com/en-us/library/ms711472(VS.85).aspx Redkar, A., Walzar, C., Boyd, S., Costall, R., Rabold, K., & Redkar, T. (2004). Pro MSMQ: Microsoft Message queue programming. USA: Springer. Riad, A. M., Hassan, A. E., & Hassan, Q. F. (2010). Design of SOA-based Grid Computing with Enterprise Service Bus. Retrieved June 7, 2010, from Design of SOA-based Grid Computing with Enterprise Service Bus: http://www.aicit.org/aiss/ppl/6.pdf Turner, R. (2005). Developing Distributed Services Today. Retrieved June 7, 2010, from Developing Distributed Services Today: http://msdn.microsoft.com/en-us/library/ms996406.aspx Read More