A Choice Between Interoperability and Migration

A CHOICE BETWEEN INTEROPERABILITY AND MIGRATION

by

CHAITANYA KURADA

Bachelor of Technology, Acharya Nagarjuna University, India, 2004

A REPORT

submitted in partial fulfillment of the requirements for the degree

MASTER OF SCIENCE

Department of Computing and Information Sciences

College of Engineering

KANSAS STATE UNIVERSITY

Manhattan, Kansas

2006

Approved by:

Major Professor

Dr. Daniel Andresen

ABSTRACT

Many of the websites today are mainly based on the J2EE standard or the Microsoft.NET architecture and use similar client-server technologies. ASP.NET provides a fast means of developing a rich user interface while the J2EE standard provides more flexibility with the business logic tier. Companies that use J2EE technology are bound to using JSP/Struts/Spring for their presentation layer. Companies that want a few applications with the interface in asp.net but are currently using J2EE technology have either the option of migrating their business logic to a new server like IIS for these applications or build web services and use them from their presentation layer in asp.net, i.e. giving their system a heterogeneous architecture.

This project tries to analyze the choice of interoperability as opposed to migration and answers the question of feasibility in merging the presentation layer in an ASP.NET framework with a business layer written in J2EE while developing a fully functional E-Commerce website. It also addresses the issues and challenges that could occur in developing such a heterogeneous website. The business logic in J2EE is built using EJB’s which is exposed to the asp.net client using web services. The feasibility of such a heterogeneous architecture is primarily dependent upon the response time of the web server to fulfill the requests. The first part of the report gives the details of the implementation while the latter gives details about the testing and draws conclusions based on the results of the testing.

TABLE OF CONTENTS

LIST OF FIGURES v

LIST OF TABLES vi

ACKNOWLEDGEMENTS vii

CHAPTER 1 - Introduction 1

CHAPTER 2 - KEY TECHNOLOGIES INVOLVED 3

2.1 ASP.NET 3

2.2 J2EE 4

2.3 Interoperability Technologies 5

2.3.1 Microsoft DCOM. 5

2.3.2 CORBA/ Java RMI 6

2.3.3 Web Services 6

2.3.3.1 Web Services Technologies 8

2.3.3.2 Web Service Invocation 10

CHAPTER 3 - TOOLS AND TECHNOLOGIES USED 11

3.1 Visual Studio.NET 2003: 11

3.2 IIS 5.0 Server 11

3.3 WebLogic 8.0 Application Server/WebLogic Workshop IDE 11

3.4 Enterprise Java Beans 12

3.5 Web Services / XML 12

3.6 Ajax 13

3.7 JavaScript / DOM 13

3.8 Scriptaculous 1.6.1 14

3.9 RSS 1.0 14

CHAPTER 4 - IMPLEMENTATION 16

4.1. System Architecture 16

4.2 Use Case Diagram 17

4.3 Class Diagram 18

4.4 Database Design 20

4.5 Web Services 21

4.6 Functionality 22

CHAPTER 5 - INTEROPERABILITY, A PROGRAMMER’S PERSPECTIVE 25

CHAPTER 6 - TESTING 27

6.1 Unit Testing 27

6.2 Performance Testing 29

CHAPTER 7 - EXPERIENCES AND PROJECT METRICS 35

7.1 Problems faced 35

7.2 Overall Experience 35

7.3 Project metrics 36

CHAPTER 8 - CONCLUSION AND FUTURE WORK 37

8.1 Conclusion 37

8.2 Future work 37

8.2.1 Implementation 37

8.2.3 Testing 37

REFERENCES 39

LIST OF FIGURES

Figure 1: Architecture of ASP.NET Framework [2] 3

Figure 2: Architecture of J2EE 5

Figure 3: Web Services Technologies [2] 8

Figure 4: Web Service Invocation [3] 10

Figure 5: Format of RSS feed [4] 15

Figure 6: System Architecture 16

Figure 7: Customer Use case diagram 17

Figure 8: System use case diagram 18

Figure 9: Class diagram 19

Figure 10: Database Relational Schema 20

Figure 11: Snapshot of NUnit testing 28

Figure 12: Graphical view of the performance under heavy load 31

LIST OF TABLES

Table 1: Configuration of System 27

Table 2: Summary of test results 30

Table 3: Overall analysis of the test suites 34

Table 4: Lines of code/ number of classes 37

ACKNOWLEDGEMENTS

My special thanks to my major professor Dr. Daniel Andresen for giving me timely advice, encouragement, and guidance throughout the project.

I would also like to thank Dr. Gurdip Singh and Dr. Mitchell Neilsen for graciously accepting to serve on my committee.

I would like to thank the administrative and technical support staff of the department of CIS for their support throughout my graduate study.

vii

CHAPTER 1 - Introduction

Software companies that are bound to using a technology like J2EE for their applications might want to consider moving their presentation layer to a different technology like ASP.NET, as .NET offers advanced features to build attractive web pages. In such situations, the companies have two options.

1.  The option of moving their entire business logic to a new asp.net server and rewriting the entire code in asp.net or

2.  Expose the existing business logic of J2EE to the asp.net client without having to rewrite the entire code in asp.net.

The first option is referred to as migration and the latter is referred to as interoperability.

Migration gives the system a homogeneous architecture whereas interoperability gives the system a heterogeneous architecture.

The decision of choosing between migration and interoperability is dependent on the following factors.

1.  Migration needs the programmers to be experienced in the other platform.

2.  If the business logic is complex, the time frame should be considerably large for migration.

3.  Interoperability needs the complete knowledge of the business logic and the ease to expose it to the outside world.

4.  Performance of the interoperated services.

This project analyses the feasibility in exposing the J2EE business logic from a programmer’s perspective by developing an E-Commerce web site and then compares the performance of the web server in a homogeneous architecture to that in a heterogeneous one. The user interface and functionality of this website is inspired from the online shopping site of ‘finishline’ [11]. The first two chapters talk about the technologies needed to build a cross platform based website and the tools and technologies used to develop this website. Chapter 4 talks about the details of implementation, architecture, and functionality while Chapter 5 throws a light on the programmer’s perspective of developing an interoperable website. Chapter 6 talks about the testing and compares the performance of the web server in a homogeneous architecture vis-à-vis the performance in a heterogeneous one. The later chapters talk about the future work and conclusions derived.

CHAPTER 2 - KEY TECHNOLOGIES INVOLVED

This chapter discusses the technologies that are needed to integrate two heterogeneous platforms to achieve interoperability. The platforms considered here are the J2EE standard and Microsoft’s ASP.NET.

2.1 ASP.NET

Microsoft has introduced ASP.NET, a new version of ASP, which allows the developers to build Web applications with great ease, courtesy of its highly advanced IDE, Visual Studio .NET. ASP.NET and Web Services are the main components of what is called the .NET framework (Fig 1).One of the most significant features of the .NET framework is it enables code written in multiple languages to work together seamlessly. One of the significant improvements in ASP.NET is the way the code is handled at run time. Instead of interpreting the page source each time a client requests a page; ASP.NET seamlessly compiles the page to Microsoft intermediate language (MSIL) code the first time the page is requested. Once the page is compiled in MSIL, the just-in-time (JIT) compiler converts the MSIL to native code.

Figure 1: Architecture of ASP.NET Framework [2]

Layered on top of the system services is the CLR which loads and runs code written in any language which targets the runtime. The .NET Framework classes provide classes that can be called from any .NET enabled language. On the top of the .NET Framework class library is ADO.NET and XML data. ADO.NET is a set of classes that provide data access support for the .NET Framework based on ADO but to work with XML and work in a disconnected environment. On top of ADO.NET and XML lies specific support for two different types of applications. One is the traditional client application that uses window Forms and the other is ASP.NET which offers Web Forms and XML Web Services. On top of these is the common language specification which ensures that each language has a common set of features.

2.2 J2EE

The Java 2 Platform, Enterprise Edition (J2EE) was designed to simplify complex problems with the development, deployment, and management of multi-tier enterprise solutions. J2EE is an industry standard, and is the result of a large industry initiative led by Sun Microsystems.

J2EE has historically been architecture for building server-side deployments in the Java programming language. It can be used to build traditional web sites, software components, or packaged applications. J2EE has been extended to include support for building XML-based web services as well. These web services can interoperate with other web services that may or may not have been written to the J2EE standard.

Figure 2: Architecture of J2EE

2.3 Interoperability Technologies

To allow the two heterogeneous platforms discussed above to interoperate, we need a technology that can communicate with both of these irrespective of the architecture of the underlying system. There are many such technologies which are designed to facilitate the leveraging of remote components. This section throws light on such technologies, their merits, and demerits.

2.3.1 Microsoft DCOM.

The Microsoft Distributed Component Object Model (DCOM), a distributed object infrastructure that allows an application to invoke Component Object Model (COM) components installed on another server, has been ported to a number of non-Windows platforms. But DCOM has never gained wide acceptance on these platforms, so it is rarely used to facilitate communication between Windows and non-Windows computers. ERP software vendors often create components for the Windows platform that communicate with the back- end system via a proprietary protocol.

2.3.2 CORBA/Java RMI

CORBA is the acronym for Common Object Request Broker Architecture, OMG's open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.

Disadvantages of CORBA/RMI/DCOM

Since we want a .NET client written in C sharp to communicate with the EJB business logic written in Java, we need a technology that is both platform independent and language independent. Java RMI can be used for accessing remote services but since it is tightly coupled to the Java language it is not suitable for interoperating between two different languages. CORBA has been used since the 90’s as a technology to access remote services. Though CORBA is platform independent and has high performance, it is generally not suitable for web interfaces. Also, CORBA uses the IIOP protocol for communication, which does not have a specific port. Security conscious network administrators can install firewalls which can filter these IIOP messages. Also CORBA needs the ORB object to be installed on both the client and the server to leverage remote components. DCOM and its successor .NET Remoting can only be used for homogeneous architectures, i.e., both the client and server need to be using the .NET technology. Hence none of the above technologies are suitable for interoperating,

2.3.3 Web Services

With the advent of XML technology most of the problems discussed above are solved by what is known today as a Web Service. Web services are building blocks for creating open distributed systems, and allow companies and individuals to quickly and cheaply make their digital assets available worldwide. They have the following advantages

¨  Interoperability: Web Services can be consumed by clients on other platforms.

¨  Internet friendliness: They work well for supporting clients that access the remote service from the Internet.

¨  Strongly typed interfaces: There is no ambiguity about the type of data sent to and received from a remote service. Furthermore, data types map reasonably well to data types defined by most procedural programming languages.

¨  Ability to leverage existing Internet standards: Web Services leverage existing Internet standards as much as possible and avoid reinventing solutions to problems that have already been solved.

¨  Support for any language: Web Services are not tightly coupled to a particular programming language. Java RMI, for example, is tightly coupled to the Java language. It would be difficult to invoke functionality on a remote Java object from Visual Basic or Perl. A client can be able to implement a new Web service or use an existing Web service regardless of the programming language in which the client was written.

¨  Support for any distributed component infrastructure: They are not tightly coupled to a particular component infrastructure. In fact, you need purchase, install, or maintain a distributed object infrastructure to build a new remote service or consume an existing service. The underlying protocols facilitate a base level of communication between existing distributed object infrastructures such as DCOM and CORBA.

2.3.3.1 Web Services Technologies

Figure 3: Web Services Technologies [2]

The four main components of web services are:

1. Extensible Markup Language (XML)

XML happened to be the de facto language of Web Service technology. However, it also has the more general purpose within the confines of Internet technology, of simply making data portable. Like HTML, XML is a markup language and has its roots in SGML; thus, it’s a specification for “tagging” documents in a meaningful way. Unlike HTML, which provides means for visualizing data, XML allows data to be self-describing and structured and so is meant primarily for the interchange of the data, not its visualization. XML is human legible and is the language by which Web service requests are issued and corresponding responses are delivered.

2. Simple Object Access Protocol (SOAP)

Simple Object Access Protocol, a lightweight XML-based messaging protocol used to encode the information in Web service request and response messages before sending them over a network. SOAP messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols, including SMTP, MIME, FTP, and HTTP. By having a standard transport mechanism, heterogeneous clients, and servers become interoperable.