Porting Guidelines

High-Level Considerations

On the surface C# has many similarities to Java, and it would appear that a code-based port, where you take the C# code and translate it into Java, would be relatively straightforward, with only a few minor differences in semantics. It isn't. This is because in most cases, the code is written to use a specific class library. In the case of .NET, this library is defined by the .NET framework and any custom add-ons that are used. In the case of Java, this library is the Java SE, Java EE SDKs and any other custom add-ons used. While the language syntax is pretty similar between the two, the frameworks are going to be different in many ways, making a straight translation difficult.

As such, it is more accurate to think about translating an application from one that runs on the .NET Framework to one that runs on a Java SE/Java EE environment. When thinking about the translation in this way, it becomes easier (and more accurate) to isolate the potential issues that are faced in migration.

A number of these issues are

• Optimization While Java and C# are syntactically similar, the underlying class libraries that do the bulk of the work in any application are vastly different. For example if a dynamic array is needed and coding were natively done in Java, a java.util.Vector could be used, whereas in C# there would be an array type.

• Suitability There may be a way of doing things in .NET that isn't suitable for the Java Platform. For example, a session-based Web service may require lots of custom code using ViewState when developed in C# for .NET but could be implemented as a session bean in EJB, where there is no direct translation of code between the two. In addition, recoding an element in this way also breaks the direct translation of modules that depend on this one, leading to cascading amounts of poor suitability for translation.

• Introduction of runtime errors There may be a number of cases where at runtime a .NET class may allow for specific bounds, but the equivalent Java one may have different boundsand in a straight line for line translation you could potentially introduce new run-time errors. One example is the concept of a connection string for a database. In both .NET and Java, the data type is the same (String), but the JDBC syntax for a connection string differs hugely from ADO.NET syntax.

• Dependencies In many cases a .NET application may have dependencies that cannot be directly translated into Java or would require additional license cost to purchase Java-specific versions. For example, if there is a dependency on a .NET specific third-party control, an equivalent control for Java would have to be found and the code translated to match the API of that control.

• Application lifecycle While there may be tools and technologies deployed on one platform to develop, test, deploy, and execute enterprise applications, porting an application to a different platform may require a different set of tools and technologies to achieve the same tasks. For example, Web application request processing in Java is commonly accomplished by using Struts framework that won't transparently get deployed during the migration process. It is important that the migration process starts with the architectural discussion of most optimal transition.

• Systemic qualities While porting a .NET application to Java, is it critical to assess various systemic qualities that are employed by the existing application architecture. Should it be a pessimistic locking for higher degree of reliability or configurable access control policies for security, the migration team has to scrutinize individual application requirements to adequately translate them to Java EE.

• Understanding deployment One of the areas to address when moving applications from .NET to Java pertains to deployment. Microsoft Visual Studio.NET simplifies the application deployment process. When using it on the same machine that the application is to be run on, the deployment is implicit. When it needs to be moved to staging or production machines, tools that come with the IDE allow one to generate an installation script. One of the advantages of the Java EE platform, its diversity; it yields different deployment tasks for individual Web and application servers such as Tomcat, WebLogic, or Sun Application Server. Therefore when translating code from the .NET environment to a Java-based one, the developer will have to understand deployment specifics in the target environment. Deployment tasks are typically automated by the Web-based tools bundled with Java EE application server or ant scripts that can be easily configured for the target environment. The coming example works with deployment into Tomcat 5.0. The ant script demonstrated in this chapter can be used to build and deploy the application.

Strategies for Porting Enterprise Applications

There are many strategies and patterns that could be followed for porting Enterprise Applications, but the overarching desire behind all of them is to do it at minimum cost and with minimal disruption to the systems. One very useful strategy to enable this is to migrate in small steps and to use Web services at every application boundary. As Web services are based on known standards at the interface, namely Simple Object Access Protocol (SOAP), it doesn't matter how they are physically implemented. A Web service is in fact an abstract entity, accessed via HTTP using SOAP documents. If .NET applications are not currently implemented using Web services, a good first step would be to implement them as Web services. One can then take the interface to these Web services, which is defined using a standard language (Web Services Definition Language or WSDL), and create new Java-based Web services from this interface description. The systems that interface to this won't know the difference that providing the WSDL for the Java Web service is the same as that for the .NET. This gives a step-by-step migration which will help minimize disruption to operational systems.

The example that will be used for porting is based on the Web Services Interoperability Organization (WS-I), Supply Chain Management application [WSI-1], used throughout this book. The Web services-based distributed Supply Chain Management application manages the request for a product through the consumer making an online purchase, a number of warehouses that may stock the required item, and the manufacturers of the cataloged items. It is a good example for an application that shows a number of different organizations with potentially different IT infrastructures operating together. This chapter looks at the relationship between the Retailer that sells the goods and its warehouse and the services that implement this relationship.

Figure 16-1 provides a high-level diagram of .NET Retailer system services that will be ported to Java EE.

Figure 16-1. .NET Retailer Service consuming .NET Warehouse service

The first thing to look at is how these services are built in C# and running on the .NET platform and then migrating them to Java EE in two ways: using Mainsoft's Visual MainWin and by manually rewriting the code from C# to Java. This provides a nice hands-on use case for a migration, as initially one ports the Warehouse service and leaves the Retailer one as-isyet the application still works across the technology boundaries with a .NET-based Retailer service and a Java-based Warehouse service. This is shown in Figure 16-2.

Figure 16-2. .NET Retailer service consuming Java EE Warehouse service

Finally, the Retailer is ported in the same manner. This also shows an additional benefit of Service Oriented Architecture (SOA) and how it can reduce the costs and risks of incrementally porting projects due to their loosely coupled nature. The final set of components are shown in Figure 16-3.

Figure 16-3. Java EE Retailer service consuming Java EE Warehouse ShipGoods service

This isn't the only strategy of course; there are many ways to achieve migration with minimal fuss, but this is a very useful one and is the basis of many of the examples in this chapter.