For many businesses, the Web storefront is the only point of contact for customers, and for others it's a major one. As such, it's important that this architecture meets the needs of your business, not just from a technology point of view but from a strategic one. No business likes to have an important asset be vulnerable to the whims of a particular vendor, and this is particularly true of a technology asset. As you probably know in IT there are two broad options that can implement your business needs: the Microsoft family of Windows and .NET products, and the open standards community.

The Microsoft option is compelling given the Visual Studio.NET development tools that are so incredibly productive in implementing software - and this is key in the success of the .NET framework. However, if you use Microsoft you're locked into a single vendor and potentially exposed to changes in its strategy or technology. If your inclination is to migrate to architectures that are no longer single vendor-dependent then J2EE provides a runtime environment that's generally considered superior to .NET insofar as scalability, security, manageability, and flexibility are concerned, and you have a choice of operating systems on which to run including Windows, Unix, Solaris, and of course Linux.

If you've ever considered taking your existing .NET server code and migrating it to run on J2EE and Linux or any other operating system, you would probably have deduced or heard that despite the surface similarities between C# and Java, the differences between the underlying class libraries and runtimes will make it unfeasible to migrate and easier to re-architect from the ground up. However, using the right combination of best practices and a tool from Mainsoft called Visual MainWin for J2EE, you'll find out that it isn't just possible to do this - but in some cases it's actually easy. By following these best practices for application design and using this tool for application migration, you'll find that the process will be orders of magnitude faster than trying to port by hand.

The Price of High Productivity
The Visual Studio.NET development environment is a very impressive tool that empowers developers to build applications quickly. It comes bundled with many controls that let you do drag-and-drop development, saving you from writing many hundreds of lines of code. However this productivity leads a developer to write monolithic applications.

Take the case of a simple Web app that retrieves data from a database, enriches the data through analytics, and then presents the data in a Web-based user interface. Using the Visual Studio.NET IDE you can easily create a Web application with an ASPX Web Form for the user interface. On this form you drag-and-drop controls that manage the connection to the database, generate data classes that represent the data for you, bind the visual controls to the data, and off you go. In some cases, you can build the application without writing any code whatsoever.

The cost of such high productivity is that the entire application is effectively a single tier. There's no separation of the retrieval, representation, logic, and presentation tiers; they're all blended into a single application domain in a 'Solution Workspace' in the Visual Studio.NET IDE.

It's important to note that Visual Studio.NET doesn't force this on you - there's nothing to stop you from building an application in separate tiers, but, it's a typical scenario that the IDE is designed to handle and is optimized for.

In trying to port an application like this to Java to run on the J2EE framework, you'll face a number of problems. Much of the C# code that's been generated for you by the IDE uses the .NET class libraries, and these libraries have a different structure than the corresponding Java ones, which makes the code that uses them impossible to port without rewriting. In many cases, C# supports functions that Java doesn't, and vice-versa, so you can end up either having to rewrite your code in the first case, or having code that isn't optimized for Java in the latter. In addition many user controls, or user interface controls that make the high-productivity, low-coding environment possible, don't have source code available for you to translate, so you'll have to rewrite them from scratch.

It makes for a difficult and expensive porting proposition.

If you have a monolithic .NET-based application there are a number of best practices in architecting your .NET application that will make the porting process easier and let the Java version of your application use your mainframe's full J2EE capabilities. Depending on your requirements, you could simply use the Visual MainWin for J2EE tool to port it as-is, getting yourself up and running quickly. But before jumping into that, it's worth looking at the best practices that will help you get the most out of the J2EE platform after migration. Then you can decide.

Best Practice 1: Design as an N-Tier Loosely Coupled Architecture
The same application can be re architected to be loosely coupled and operate in tiers. You can see a sample high-level architecture in Figure 1. The overall application has been split into four application domains, each one being a tier in the architecture. These are:

• Data Tier: This is where the data is stored usually in a relational database, but it can also be in a flat file format, or a service behind a HTTP, or other server that delivers data to you. When implementing your database behind a data retrieval tier, you're not limited to Microsoft SQL Server, and can use various Open Source or low-cost databases such as PostgreSQL or MySQL.
• Data Retrieval Tier: This is a tier that understands the Data Domain and how to access data on it. So if for example the Data Domain contains a DB2 database, the data retrieval tier has JDBC connectors for DB2 and logic that wraps these connectors that your application can use. This tier has knowledge of the specific queries or stored procedures that your application needs, and can execute them on the data store.
• Data Enrichment and Business Logic Tier: This tier gathers information from one or more data retrieval applications and applies business logic to this data. The business logic can take many forms including analytics, data enrichment and data aggregation as shown in the diagram.
• Presentation Tier: This tier contains the logic to present a visual interface to your users and all logic required to pass their input to the business logic tier as well as return information to them from the business logic tier.

Best Practice 2: Use Web Services in the Middleware
The data retrieval tier and the business logic tier make up the middleware of the system. They're the hub around which the system runs and the important value-added middle ground between the user interface and the underlying data. If they could be implemented as Web Services, you could buy a lot of flexibility for your port.

This is because a Web Service isn't a physical implementation of logic. It's an abstract entity that defines the interface to the underlying physical implementation. This interface is defined using an XML-based language called WSDL (Web Services Description Language), an open standard supported by all vendors that lets you communicate with the underlying functionality using a document constructed out of another standard XML-based language called SOAP (Simple Object Access Protocol).