For demonstration purposes, I have created a simple .NET Windows application. To explore the advantages of .NET's language interoperability feature, you will create the client using VB .NET. However, you will use both the COBOL .NET and VB .NET sample serviced components .
Name the client application ServicedComponentClientVB.sln. As shown in Figure 19-30, you will add three references using the VS .NET Add Reference feature via the Solution Explorer window.
As you can see in Figure 19-30, the two references for your sample application . dlls and the one reference for the System.EnterpriseServices assembly have been added. The next step is to add a small amount of code. Additionally, you need to add two buttons and a TextBox to the Windows Form. Use the code in Listing 19-9 to make the client application complete. The code uses both the COBOL .NET and VB .NET sample serviced components. Language interopera bility is great!
Private Sub Button1_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button1.Click Try Dim mycobolclass As New MyFirstClassLibraryCobol.MyFirstClass() Dim mystring As String = _ mycobolclass.DoTransaction("Remove This String To Test Exception") TextBox1.Text = mystring Catch myexception As ArgumentException Trace.Write(myexception.Message) Catch myexception As Exception Trace.Write(myexception.Message) End Try Private Sub Button2_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button2.Click Dim myvbclass As New MyFirstClassLibraryVB.MyFirstClassLibraryVB() Dim mystring As String = myvbclass.DoTransaction TextBox1.Text = mystring End Sub
As shown in Figure 19-31, the simple GUI for your client application is created to make clear which COM+ application will be used as you click either button.
Before you click either of the buttons, open the Component Services console window and navigate to the Running Processes node. Then, as you proceed to click each client application (ServicedComponentClientVB) button, observe the activity reflected within the Running Processes folder/node. Figure 19-32 shows ServicedComponentClientVB as an active process with two COM+ applications.
If you take a peek at the right pane in the Running Processes folder/node, you can drill down into each displayed item. Various views are available. As you can see in Figure 19-33, each COM+ application is exposing its unique ID.
Explore with the Component Services console tool. Using a set of sample applications such as the ones created in this chapter, you can safely explore. I'm sure that you get the sense of the feature-richness tucked away inside the COM+ product.
Tip | Consider modifying the sample applications to really take advantage of the transaction support. For example, you can expand on the exception logic that you have been shown in the sample applications to experiment with aborted transactions. |
The following sections introduce other COM+ features that are available to you. As mentioned earlier, COM+ offers many services. Picking from COM+'s impressive feature list, I briefly cover the features Object Pooling and Queued Components.
Object Pooling is a feature that allows COM+ to preinstantiate a pool of objects for your COM+ application. Then, as a client application makes a call to use an instance of your serviced component, COM+ will first check to see if an object is available in the pool. If so, an object is provided from the pool. If not, a new object is instantiated (up to the specified maximum pool size limit).
You may want to consider the COM+ Object Pooling feature if
The cost incurred by executing your object's constructor is expensive relative to the length of time it takes for a client to use and release your object.
You need to limit the number of concurrent objects. For example, there may be restrictions to resource connections or licenses.
There is no thread affinity and no client state being used.
Assuming that your application meets each of the preceding requirements, Object Pooling may be right for you. When you use it properly, this COM+ feature can bring performance and scalability improvements.
To enable Object Pooling, navigate to the Activation tab. For demonstration purposes, in Figure 19-34 I have checked the "Enable object pooling" check box. Additionally, I have changed the Minimum Pool Size from 0 to 5.
In addition to using the Properties page (as shown in Figure 19-34) to enable the Object Pooling feature, you can use attributes in your code. Recall the list of attributes shown in the section "Other System.EnterpriseServices Attributes . "
Use the sample applications provided in this chapter to freely explore the Object Pooling feature. I suggest that you enable Object Pooling on the sample COM+ application. Then, using a sample client application, notice the results. By the way, you will notice that the pooled objects all share the same CLSID. Refer ences are provided at the end of this chapter in the "To Learn More" section to assist you as you explore this and other COM+ features.
The COM+ Queued Components feature will certainly remind you of a product you may have worked with on the mainframe: IBM's MQSeries. That's right. Working with Queued Components will introduce (or reintroduce) you to the world of application messaging and guaranteed delivery. The COM+ Queued Components feature works closely with Microsoft's messaging product, which is called Microsoft Message Queuing (MSMQ).
Note | MSMQ's full feature set stretches far beyond the support of Queued Components. The discussion in this section simply scratches the surface of MSMQ's full potential. |
You might consider using Queued Components if
Guaranteed delivery is critical. That is, when a client application makes a call to your serviced component, is it critical that the call is completed, even if it's done asynchronously.
There is a need to provide support to your client application, even if the serviced component (the server application) is temporarily offline.
The requirement to install your component on both the client and server machines does not pose any deployment concerns.
The need to have COM+ and MSMQ installed on both the client and server machines does not pose any deployment concerns.
These are just a few points to consider. I am sure there are more. In the meantime, as you browse the Properties page of your COM+ application, under stand that when you come across the Queuing tab (see Figure 19-35), you will see one of the starting points for using the Queued Components feature.
As shown in Figure 19-35, I have modified the properties of the COBOL .NET sample COM+ application to become a queued component. In doing so, I needed to change the activation type property from Server to Library. After I did this, COM+ automatically created private queues for my new queued component in MSMQ.
To verify this for yourself, simply navigate to the Computer Management console (click the Start button and select Programs Administrative Tools Computer Management or simply right-click your My Computer icon and choose Manage). Check to make sure that you have the MSMQ product installed and that the Message Queuing Windows Service is started. Then, using the Computer Man agement console, you will see the MSMQ snap-in listed as Message Queuing along with your new private queues (see Figure 19-36). Not bad!
Add in the needed code and design considerations, and you are well on your way to using the Queued Components feature of COM+. Unfortunately, I need to stop here and miss out on the fun. Please be my guest and continue on to com plete this learning journey.