Important Concepts for Distributed Applications

Important Concepts for Distributed Applications

Since our topic is building large-scale distributed applications in Visual Basic .NET, now would be a good time to take a step back and provide an overview of the concepts that are important for understanding the benefits and trade-offs of the possible approaches. Writing smaller applications usually does not require a great deal of planning or design work. Issues such as calling overhead and latency don t typically rear their heads in smaller applications. Larger-scale applications, however, are a far different beast. For the purposes of this chapter, we define a distributed application as an application in which one or more of the logical tiers are located on remote machines. It is critically important to be aware of the design issues that can potentially make or break such an application. To this end, this section looks at three important concepts in large-scale distributed application development:

• Loosely coupled and tightly coupled applications

• Overhead involved in method calls

• Componentization and logical organization

Loosely Coupled vs. Tightly Coupled Applications

Imagine using a standard platform-independent communication mechanism between remote (network-separated) application segments (think SOAP). What this does is enable you to develop applications that have no knowledge or understanding of either participating system. In this scenario, you agree only on the communications mechanism. The platforms can vary wildly. In .NET, two systems are considered loosely coupled if the only mandate imposed on them both is to understand self-describing, text-based messages.

Tightly coupled systems, on the other hand, impose a significant amount of customized overhead to enable communication and require a greater understanding between the systems (think Distributed Common Object Model [DCOM] or remoting). A tightly coupled application requires that there be a greater level of system integration and dependence. A loosely coupled system is far less prone to problems with system setup, as long as the minimum communication requirements are met.

The other side to coupling is the overhead requirement. A loosely coupled system imposes greater marshaling overhead. The native binary format must be translated to something that both systems can understand. It is then the responsibility of the target system to parse that message and convert it to a format that it understands. A tightly coupled application does not need to translate to and from a universal format. Typically the network format is binary and is well understood by both parties, requiring less translation and, by extension, the use of fewer processing resources.

Overhead in Method Invocation

When you are developing a distributed application, you need to be aware of the limitations of this type of application. In a standard application, you typically don t worry about the processing overhead of function calls. These calls are typically limited only by the speed of your computer. Moving to the network introduces more variables into the equation.

Figure 21-1 demonstrates the relative differences in the overhead of method calls, depending on where the target resides. As you can see, in-process method invocation has very little calling overhead. Out-of-process method invocation introduces more overhead, due to marshaling across the process boundaries. This type of invocation involves communicating with another application on the local computer (such as a Microsoft Windows service or a COM+ server application). Remote process method invocation brings into play not just process-boundary marshaling but also network latency. This typically means a vastly greater calling overhead than any of the other options and implies the need for a different approach to the application s architecture.

Figure 21-1

Overhead of method calls in different contexts.

So while we can call into local methods without any concern for overhead, and even out-of-process overhead isn t too bad, we need to be extra careful of not only how often we call remote methods but also how much work these methods do. Think of it this way: since the overhead is greater, we need to make the method calls worthwhile. Consider the following example to help demonstrate what we mean. It shows the difference between setting properties on an object a typically simple operation with low overhead and using a single method to set all the properties at once.

' Approach 1   Don't do this for a remote or out-of-process object Obj.Property1 = val1 Obj.Property2 = val2 Obj.Property3 = val3 Obj.Property4 = val4 Obj.Property5 = val5 ' Approach 2   Better for a remote or out-of-process object Obj.SetValues(val1, val2, val3, val4, val5)

This example uses two different approaches, but it does not really clarify why one is better than the other. For this, look to Figure 21-2. It should help you visualize the differences between the approaches and understand how they affect an application s performance. Approach 1 is chatty in that each property access involves a separate network operation, whereas approach 2 is chunky because it accomplishes its task with a single network operation.

Figure 21-2

Remote objects and the effect of network latency.

At this point, it should be clear that the design of your remote objects and interface is vitally important to your application s scalability and performance. When you look at the performance of approach 1, you should also understand that when you access any remote object you are consuming resources on the remote server, which means that fewer connections are available to other applications. The more efficient your design, the better your application will perform and the better it will scale up in an enterprise environment.

Componentization and Logical Organization

Componentization is an extremely important concept for any large-scale application. It is more than just a separation based on the functional tiers of your application (such as user interface, business logic, and the data tier). It is also the separation of functional areas within individual tiers into specific components. This separation has several benefits. Imagine a customer management application. You might divide the server-side components into database, business logic, and general utility components, as shown in Figure 21-3. This structure gives you the ability to concentrate all of the database logic into a single area of the application and manage database changes through versions in a more feasible fashion.

Figure 21-3

Hypothetical componentized application.

From the standpoint of upgrading, logical separation of code enables a smoother approach to upgrading larger applications. It gives you more choices regarding what to upgrade and how to upgrade your application within a given application. So before you undertake any upgrading tasks, it makes a lot of sense to analyze your application and look at ways to partition the logic into separate containers and to consider the option of leaving some code in Visual Basic 6 while upgrading elements that could derive immediate benefits.