Migration of a Visual C++ Application to Visual C++.NET When migrating the PMS to the .NET environment, we had two options: either migrate the entire PMS to .NET or migrate it partially. We have opted for the second alternative. The front end of the PMS and AdminServices.dll will essentially remain unchanged, whereas the CustomerServices.dll will be converted into various Web services. This will help us better understand the interoperability part of the migration. As mentioned, the CustomerServices.dll is converted into two types of Web services. The scheme of the conversion is shown in Figure 14-11. Figure 14-11. Block diagram of Visual C++.NET PMS.  StockInfoWebService The StockInfoWebServices module gives information about stocks. It encapsulates three methods : String * GetStocks() String* GetStockPerformace() String* GetStockPrice(String * strStockID) This module is written as a managed C++ Web service. This Web service can be accessed using the .asmx file. The general format of accessing this Web service is as follows : http: // <Server name > / StockInfoWebService / StockInfoWeb Service.asmx / <MethodName>?<param1> & <param2> & Here we are not rewriting the business logic. We are using the same COM components that we used in the previous version. However, as you know from the previous chapter, we cannot use the COM component in managed code directly. We will have to convert this COM component in the .NET assembly first. To do this we use the command-line utility tlbimp.exe. For more details of tlbimp.exe and .NET assembly, please refer to Chapter 9. The objective of migrating this ISAPI to a managed C++ Web service is to show that the existing COM components can be smoothly integrated with the managed code. The other aspect is migrating the existing ISAPI DLLs to managed C++ Web services. The development of the ISAPI DLL takes a lot of time due to the tedious process of debugging. On the other hand, we can debug the managed C++ Web service very easily, just like another executable and can do it in the .NET IDE itself. This reduces the time taken for development of Web applications. Generally, in the multi- tier systems, ISAPI DLLs are wrapped around the business components, and they don't have any business logic. It is easy to migrate such wrapper components by keeping your investment in business components still intact. This migration shows how easy it is to migrate the ISAPI to managed C++ Web service. SessionsWebService The SessionWebService module exposes the login and related services and also gives the customer details. Here we are using two COM components VCLoginCom and VCReportsCom. The Web services are created using the ATL Server. It encapsulates four methods:  [ tag_name(name="Login") ] HTTP_CODE OnLogin(); [ tag_name(name="Logout") ] HTTP_CODE OnLogout(); [ tag_name(name="ChangePassword") ] HTTP_CODE OnChangePassword(); [ tag_name(name="GetCustomerDetails") ] HTTP_CODE OnGetCustomerDetails(); Because this Web service is written in unmanaged code, we can directly use the COM component without converting it into a .NET assembly. You have read the introduction to the ATL Server in Chapter 8 and you know that it creates the .srf file for Web service discovery. We have created one .srf file per method, and you access the methods using these .srf files. Note that per the ATL Server project, by default only one .srf file is created. The rest of the files have to be created manually. The .srf file will contain the tag name, and during parsing, this tag will be replaced by the actual method. For example, in the .srf file when the Login tag is encountered in the {{}} placeholder, it is replaced by the function call OnLogin() . The parameters are passed using the name-value pair, similar to ASP. The general format of accessing the ATL Server method through the browser is http : // <server name> / < folder name> / < .srf file name> / <<param1>=<value1>> & <<param2>=value2> & In this component migration, we have tried to explore the features available with the ATL Server. Here we can use the existing COM component as is; there is no need to convert it into .NET assembly. Here we have explored the .srf files and depicted how easily we can replace the ISAPI calling convention with the SRF calls. This is a perfect example for the developers who want to continue using the ATL programming but want to get the maximum out of Web services. OrdersWebService The OrdersWebService module exposes the services related to the buy and sell transactions. The Web services exposed by this module are [ tag_name(name="ReportCancelledOrders") ] HTTP_CODE OnReportCancelledOrders(); [ tag_name(name="ReportApprovedOrders") ] HTTP_CODE OnReportApprovedOrders(); [ tag_name(name="GetUnapprovedOrders") ] HTTP_CODE OnGetUnapprovedOrders(); [ tag_name(name="GetPortfolioInfo") ] HTTP_CODE OnGetPortfolioInfo(); [ tag_name(name="ExecuteOrder") ] HTTP_CODE OnExecuteOrder(); Here again we created the Web services using ATL Server. In this Web service we are using two COM components, VCRecordsCom and VCOrderCom. It is essential to know that the URL given to the Inet control is not hard coded. This information is retrieved from an ini file. Let us have closer look at the ini file and how the URL is formed . The ini file before migration has the following structure: [MODULE_PATH] server=localhost PATH=scripts MODULE=CustomerServices.dll In the code we are using two functions to read from the ini file. The first function is ReadUrl String() , which is called at the application start-up. It generates the required URL and stores it. The second function, GetUrlString() , is called for all the server requests and it just returns the stored URL. Now when we migrate to the .NET environment, we will have to use a different URL for accessing the ATL Server and managed C++ Web services. So the structure of the ini file is modified to accommodate this change. The changed ini file is as follows: [MODULE_PATH] Webservice=Yes server=pc-p3796 ISAPI_PATH=scripts ISAPI=CustomerServices.dll ASMX_PATH=StockInfoWebService ASMX=StockInfoWebServices.asmx SESSION_WEB_SERVICE=SessionsWebService SESSION_SRF_LOGIN=Login.srf SESSION_SRF_LOGOUT=Logout.srf SESSION_SRF_CHANGEPASSWD=ChangePassword.srf SESSION_SRF_CUSTOMERDETAIL=GetCustomerDetails.srf ORDER_WEB_SERVICE=OrderWebService ORDER_SRF_UNAPPROVED=GetUnapprovedOrders.srf ORDER_SRF_APPROVED=ReportApprovedOrders.srf ORDER_SRF_CANCELLED=ReportCancelledOrders.srf ORDER_SRF_EXECUTE=ExecuteOrder.srf ORDER_SRF_PORTFOLIO=GetPortfolioInfo.srf But to accommodate this change, we will have to make few minor changes to our code. Earlier we stored the URL at the application start-up (using the ReadUrl String() function), but now we must check to see if the application has to use Web services or ISAPI DLL. A new method, CheckForWebServices() , is called at the start-up to determine that. If we have to connect to the ISAPI DLL, it reads and stores the URL string. The GetUrlString() method has been changed to return the stored URL string if we are connecting to an ISAPI DLL; otherwise it reads the URL for specific Web services. The GetUrlString() method now takes two strings as parameters, which are ignored if we are not connecting to a Web service and the stored URL is returned. In the case of Web services, input strings specify the specific PATH and MODULE keys to read for a particular Web service. A new method, IsWebService() , is added to the Application class, which returns a Boolean, indicating that we are to connecting to a Web service.  | 
