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
KANSASSTATEUNIVERSITY
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
LIST OF TABLES
ACKNOWLEDGEMENTS
CHAPTER 1 - Introduction
CHAPTER 2 - KEY TECHNOLOGIES INVOLVED
2.1 ASP.NET
2.2 J2EE
2.3 Interoperability Technologies
2.3.1 Microsoft DCOM.
2.3.2 CORBA/ Java RMI
2.3.3 Web Services
2.3.3.1 Web Services Technologies
2.3.3.2 Web Service Invocation
CHAPTER 3 - TOOLS AND TECHNOLOGIES USED
3.1 Visual Studio.NET 2003:
3.2 IIS 5.0 Server
3.3 WebLogic 8.0 Application Server/WebLogic Workshop IDE
3.4 Enterprise Java Beans
3.5 Web Services / XML
3.6 Ajax
3.7 JavaScript / DOM
3.8 Scriptaculous 1.6.1
3.9 RSS 1.0
CHAPTER 4 - IMPLEMENTATION
4.1. System Architecture
4.2Use Case Diagram
4.3 Class Diagram
4.4 Database Design
4.5 Web Services
4.6 Functionality
CHAPTER 5 - INTEROPERABILITY, A PROGRAMMER’S PERSPECTIVE
CHAPTER 6 - TESTING
6.1 Unit Testing
6.2 Performance Testing
CHAPTER 7 - EXPERIENCES AND PROJECT METRICS
7.1 Problems faced
7.2 Overall Experience
7.3 Project metrics
CHAPTER 8 - CONCLUSION AND FUTURE WORK
8.1 Conclusion
8.2 Future work
8.2.1 Implementation
8.2.3 Testing
REFERENCES
LIST OF FIGURES
Figure 1: Architecture of ASP.NET Framework [2]
Figure 2: Architecture of J2EE
Figure 3: Web Services Technologies [2]
Figure 4: Web Service Invocation [3]
Figure 5: Format of RSS feed [4]
Figure 6: System Architecture
Figure 7: Customer Use case diagram
Figure 8: System use case diagram
Figure 9: Class diagram
Figure 10: Database Relational Schema
Figure 11: Snapshot of NUnit testing
Figure 12: Graphical view of the performance under heavy load
LIST OF TABLES
Table 1: Configuration of System
Table 2: Summary of test results
Table 3: Overall analysis of the test suites
Table 4: Lines of code/ number of classes
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 CISfor their support throughout my graduate study.
1
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.
- Migration needs the programmers to be experienced in the other platform.
- If the business logic is complex, the time frame should be considerably large for migration.
- Interoperability needs the complete knowledge of the business logic and the ease to expose it to the outside world.
- 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 buildWeb 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 loadsand runs code written in any language which targets theruntime. The .NET Framework classes provide classes that canbe called from any .NET enabled language. On the top of the.NET Framework class library is ADO.NET and XMLdata.ADO.NET is a set of classes that provide data accesssupport for the .NET Framework based on ADO but to workwith XML and work in a disconnected environment. On top ofADO.NET and XML lies specific support for two differenttypes of applications. One is the traditional client applicationthat uses window Forms and the other is ASP.NET whichoffers Web Forms and XML Web Services. On top of these isthe common language specification which ensures that eachlanguage 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)
XMLhappened 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 makingdata 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.
3. Web Service Description Language (WSDL)
WSDL describes the public interface to the web service. This is an XML-based service description on how to communicate using the web service; namely, the protocol bindings and message formats required to interact with the web services listed in its directory. The supported operations and messages are described abstractly, and then bound to a concrete network protocol and message format.
WSDL is often used in combination with SOAP and XML Schema to provide web services over the internet. A client program connecting to a web service can read the WSDL to determine what functions are available on the server. Any special data types used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the functions listed in the WSDL.
4. Universal Description, Discovery, and Integration (UDDI)
UDDI is one of the core Web Services standards. It is designed to be interrogated by SOAP messages and to provide access to Web Services Description Language documents describing the protocol bindings and message formats required to interact with the web services listed in its directory. Business analysts and technologists use UDDI to discover available web services by searching for names, identifiers, categories, or the specifications implemented by the web service.
2.3.3.2 Web Service Invocation
Figure 4: Web Service Invocation [3]
The client querying the UDDI service initiates a typical invocation process between a client and Web service. Once the UDDI service processes the client request, it returns a URL to the Web service description file, which in this case would be a WSDL or service contract file for that particular Web service. After the client receives the URL to the service description, it sends in a request for the complete service description to the target server where the Web service is hosted. Host Server returns the service description for the Web service, which contains details about the available methods and the necessary parameters to these methods along with their type information. Once the requesting client has received the service description, it has the information needed to compose and send a properly formatted SOAP request asking the target server to invoke the method and return the results. Finally, client composes proper SOAP requests based on service description and sends them over the wire using a transport protocol, which can be HTTP, SMTP, or FTP.
CHAPTER 3 - TOOLS AND TECHNOLOGIES USED
3.1 Visual Studio.NET 2003:
I have used Visual Studio 2003 for the ASP.NET 1.1 framework installed on my system. Visual Studio.NET is the only advanced IDE that can be used as a rapid application development tool for ASP.NET. Though Microsoft introduced the free Web Matrix IDE later, Visual Studio.Net remains far more advanced and vastly used IDE. . The IDE makes creating attractive web pages a child’s play and provides built in support for XML parsing. However, it does not have the advanced features like support for Ajax, draggable content, RSS feeds etc. All these are available in ASP.NET 2.0 framework. ASP.NET 2.0 comes with a built in support for Ajax called Atlas. I had to implement these features using third party tools.
3.2 IIS 5.0 Server
IIS is the default server that comes with the XP professional operating system. Though not robust, it is simple enough to manage because of the GUI support. However, it can support only 10 simultaneous browser connections which can be a hindrance while testing.
3.3 WebLogic 8.0 Application Server/WebLogic Workshop IDE
WebLogic is the application server developed by BEA which comes with a built-in IDE which makes developing and building J2EE applications easy.WebLogic Workshop is an integrated development environment for building enterprise-class J2EE applications on the WebLogic Platform. WebLogic Workshop provides an intuitive programming model that enables us to focus on building the business logic of the application rather than on complex implementation details like deployment, creating jar files, writing deployment descriptors etc.