Distributed, Asynchronous, and Concurrent Application Models

The business applications that you build will vary greatly. The scale of the appli cations will also vary. You will build small, single- user applications; medium- sized applications; and large, enterprise-wide applications. When your development needs expand to the enterprise-wide level, you will eventually need to incorporate a few advanced .NET technologies into your arsenal. Your application designs will grow eventually to distributed, asynchronous, or concurrent application models.

That is right. Distributed, asynchronous, and concurrent application models are looked at as being "complex and advanced" topics. These application models are generally thought of as being for large-scale, multiuser, enterprise-wide Windows and Web applications. Now, what does this mean to you?

Coming from the mainframe environment, you are likely saying to yourself: "OK, Chris, what is the big deal? Application development on the mainframe is almost always about large-scale, multiuser, enterprise-wide applications."

Furthermore, you may be wondering about the simple demonstration appli cations that you have seen so far. Though you did get your feet wet with tons of great .NET technology, the applications were small and simple. My concern is that this may have left you wondering about the samples you've seen so far. Yes, you have built very simple "Hello, World" applications in most of the previous chapters.

You may be wondering why it was that the .NET console, Windows, and Web sample applications that you built did not appear to address the "enterprise-wide" type of business requirements. Looking at a simple "Hello, World" sample appli cation, it takes a giant leap of faith and imagination to visualize that same application scaling upward to handle hundreds (even thousands) of users. For the most part, this speaks to the strength of the .NET and Windows/Web platform development: You can accomplish so much with such little effort.

Yes, you experienced a high degree of simplicity in the use of many of the .NET topics covered in earlier chapters. This fact can easily mislead you into thinking that only small, single-user applications have been built using those .NET technologies (e.g., ASP.NET, ADO.NET, and so forth). This is definitely not the case. More often than not, you can use the material covered in the previous chapters to build small-, medium-, and large-scale applications.

Note  

The success of the World Wide Web can serve as a reminder of what is possible when "growing" your applications. Everything that you have learned about .NET can easily apply to all types of Windows and Web applications.

Be that as it may, you will eventually come across the need to scale your Windows and Web applications to better address special distributed, asyn chronous, or concurrent demands. You are then taking your potentially high-end application to its own next level, relatively speaking. This means that your design approach will need to incorporate techniques to answer new questions. You need to give some thought to satisfying the business requirements through a mean ingful application design. In some cases, this will mean using a distributed, asynchronous, or concurrent application model.

Planning for Distributed, Asynchronous, or Concurrent Mainframe Applications

Think for a moment about some of the mainframe applications that you built in the past. When you built large-scale, multiuser, enterprise-wide mainframe COBOL/CICS applications, what were the requirements that your application needed to address? Were there special design considerations introduced to satisfy those types of requirements? Given your background, certainly you have come across the following mainframe scenario “based questions before:

• Will you need to remotely execute your CICS transaction using Distributed Program Link (DPL), further distributing an already distributed application model?

• Does your CICS program design require you to use the CICS START and RETRIEVE commands for simultaneous transaction processing, which introduces concurrent and asynchronous processing characteristics to your application?

• With your batch COBOL program, what input class (controlling the system initiator choice) should you use in your JCL? Are there any dispatching priority settings needed for the system initiator? The concurrent nature of batch program processing is often taken for granted.

 

The topics covered in this chapter will remind you of similar distributed, asyn chronous, and concurrent mainframe technologies. For example, you can easily compare MSMQ and asynchronous processing on the Windows platform with IBM's MQSeries product and other supporting technologies that you may have used on the mainframe. You can also easily compare the .NET Remoting feature with the mainframe CICS DPL feature . Finally, the topic of .NET multithreading may remind you of CICS's inherent multitasking and multithreading capabilities and CICS's START/RETRIEVE feature.

Granted, these are rather loose comparisons. But you certainly get the point. Having said that, I will now switch gears and dive into the first one of these "complex and advanced" topics: ^[4] Microsoft Message Queuing.

^[4] Obviously, becoming informed, applying the right amount of research, and practicing can turn an otherwise "complex and advanced" topic into just another skill set under your belt, another feather in your cap, and another paragraph on your resume.