Migration

Digg This!

Page 2 of 3   « previous page   next page »

So if your middleware is built as Web Services and these services expose a WSDL interface to the consumer, how the physical service itself is constructed is irrelevant. Therefore, if you construct your middleware tiers as Web Services in .NET then, when it comes to porting them, you can replace each one in turn with a Java implementation without actually breaking the system.

If, for example, you have the data retrieval layer implemented as a .NET Web Service, you can begin porting right away. There are many tools that let you take the WSDL of this Web Service and construct a skeleton Java application out of it. You can then take this skeleton and fill in the blanks, replacing the ADO.NET-based code with new code that uses JDBC. As the set of dependent classes that you're using is relatively few (this tier is architected to be data retrieval only) it should be relatively simple to recode the Web Service to use Java instead of C#. When you're done, you simply replace the Web Service reference on the business logic layer with a reference to the new Java-based Web Service, and you should be able to switch over with a minimum of fuss.

Best Practice 3: Use Web Services Between the Presentation Layer and the Middleware
Like Best Practice 2, you can also change your business logic tier to use Web Services. This is a little more complicated since this tier is more general purpose in nature than the data retrieval tier. However the principle is the same. If you architect your .NET application to use Web Services in this tier, then the WSDL for these Web Services can be used to generate skeleton Java code for the ported versions. Then, based on the functionality of the original Web Service you'd have to deduce how to implement the logic in Java. Despite the fact that C# and Java are very similar on a syntactical level, the libraries that support them are vastly different, so applications built in one won't port easily to the other because the references to the class libraries have to change completely. This might prove an unsettling prospect when porting code and would have to be carefully considered. In fact, you might decide to keep this tier operating on .NET and have a mixed technology architecture.

The Visual MainWin J2EE option is extremely compelling here. Since it uses a port of the .NET class libraries, its job is a lot easier and it can cross-compile your existing code to run on the Java runtime. Mainsoft developers, as supporters of the Open Source community, are partners with the Mono project, and have implemented the ASP.NET and ADO.NET class libraries that Mono supports in Java so that your C# code can more easily convert to Java. You can find more details here (http://dev.mainsoft.com/Default.aspx?tabid=39). Note that this page is an ASPX, but the Web server running it is actually Linux. It's based on a port of DotNetNuke to J2EE. Another great business advantage of using this tool is that you can have a single source solution for both Microsoft and J2EE platforms. With the tool handling the conversion from .NET to J2EE for you, you can concentrate your development skills on the C# or VB.NET languages.

When converting this layer to Web Services, you'll have to have a presentation layer that understands Web Services. In the case of .NET, it's very simple to have a .NET Web Application consume a Web Service, so you're okay to go there. If you were to port this to a JSP-based application, your porting experience would vary from relatively simple (if you use simple HTML form-based controls on your UI) to extremely difficult (if you're using sophisticated .NET GUI controls such as the Calendar or Grid control). The JSP should be able to consume a Web Service easily too.

In the next section you'll see an example of this four-tier architecture, built completely in .NET, and how it can be migrated to a WebSphere J2EE Application Server using the Visual MainWin for J2EE toolkit.

Example Scenario
We'll look at a full .NET application designed for multi-currency portfolio management. For simplicity's sake, there's no data store for the portfolio itself, it's simply hard coded on the data retrieval level. However, there's a data domain that's two Web Services, one that provides a stock quote and one that provides currency exchange information. These Web Services are publicly available at Xmethods.net.

The full source code for the .NET implementation and the implementation that has been migrated to Java is available with the download for this article.

This demonstration shows data moving through all the tiers, being retrieved from the Web Services, and having business logic to handle the currency conversion as well as orchestrate the data retrieval layer to provide a portfolio.

You can see the front-end of the application in action running on Windows in Figure 2.

Migrating the Scenario in Phases
You can now follow a phased migration to move your application to WebSphere running on Linux. Remember that the data retrieval layer consumes the data domain, the business logic layer consumes the data retrieval layer, and the presentation layer consumes the data retrieval layer. To move these in a phased approach is very simple and requires very little in the way of changes to your projects. You simply migrate one layer at a time, and 'plug' the existing layer into the new one repeating piece by piece.

So, here for example are the steps in migrating the data retrieval layer (assuming Visual Studio.NET and Visual MainWin for J2EE are installed).

1. Open the data retrieval layer source code
2. Select 'Generate J2EE Project' on the Project menu
3. The wizard will now generate a new project for you containing a reference back to your original source code and all the information needed to compile and deploy this to J2EE.

The code in the sample is straightforward and should work without modification. In larger systems, some modification may be necessary - and the Visual Studio.NET environment is optimized for such code modifications. When running Visual MainWin for J2EE you can also re-use any other existing Java assets in the code such as EJBs.

As you can see, when you have this tiered system you can migrate piece by piece. The business logic layer was consuming the Web Service when it ran on .NET, and now that it runs on J2EE in Linux, all you have to do is recreate the Web reference to point at the one that's running on J2EE and it will execute. You can then repeat the process - using Visual MainWin for J2EE to migrate it to a J2EE project, run it on WebSphere in Windows, generate a WAR file, deploy the WAR file to WebSphere on Linux, and finally update the Web reference in the presentation layer to point to this one.

Finally, the presentation layer itself can be moved to Linux in the same way. Figure 3 shows the .NET application that you saw in Figure 2 (and implicitly all the tiers above it) running on SUSE Linux 8.1.

Page 2 of 3   « previous page   next page »