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 architecture and use similar client-server technologies. 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 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 , 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 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 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 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 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 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.
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 , 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 server and rewriting the entire code in or
2. Expose the existing business logic of J2EE to the client without having to rewrite the entire code in .
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.
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 .
2.1
Microsoft has introduced , 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. 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 is the way the code is handled at run time. Instead of interpreting the page source each time a client requests a page; 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.
[pic]
Figure 1: Architecture of 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 and XML data. 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 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 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
[pic]
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.
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
[pic]
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.
TOOLS AND TECHNOLOGIES USED
3.1 Visual 2003:
I have used Visual Studio 2003 for the 1.1 framework installed on my system. Visual is the only advanced IDE that can be used as a rapid application development tool for . Though Microsoft introduced the free Web Matrix IDE later, Visual 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 2.0 framework. 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.
WebLogic Workshop's intuitive user interface lets us design the application visually. Controls make it simple to encapsulate business logic and connect to enterprise resources, like databases and Enterprise JavaBeans, without writing a lot of code. Creating and deploying web services is also made very easy.
“Based on the industry agreed upon standard for Java compatible application server benchmark testing, BEA WebLogic Server currently holds the highest mark”. [6]
However it consumes a lot of memory and processor time and is a heavy weight application and is not be suitable to be installed on a laptop.
3.4 Enterprise Java Beans
Enterprise JavaBeans (EJB) technology is the server-side component architecture for Java Platform, Enterprise Edition (Java EE). EJB technology enables rapid and simplified development of distributed, transactional, secure, and portable applications based on Java technology. EJB’s are deployed in an EJB container within the application server. The specification describes how an EJB interacts with its container and how client code interacts with the container/EJB combination. I have used two types of beans for this project
1. Stateless Session Beans: Stateless session beans are distributed objects that do not have state associated with them thus allowing concurrent access to the bean. The contents of instance variables are not guaranteed to be preserved across method calls.
3. Entity Beans: Entity beans are distributed objects having persistent state. The persistent state may or may not be managed by the bean itself. Beans in which their container manages the persistent state are said to be using Container-Managed Persistence (CMP), whereas beans that manage their own state are said to be using Bean-Managed Persistence (BMP). I have used CMP entity beans for the project. The development of EJB’s was made easy by the advanced features of the WebLogic Workshop IDE.
3.5 Web Services / XML
According to the W3C a web service is a software system designed to support interoperable machine-to-machine interaction over a network. Web Services act as an interface between the two heterogeneous platforms and provide a means of cross platform access. Since the data types may be inconsistent across the different platforms, XML is used to wrap the data that is being passed across the platforms. XML provides a text-based means to describe and apply a tree-based structure to information. At its base level, all information manifests as text, interspersed with markup that indicates the information's separation into a hierarchy of character data, container-like elements, and attributes of those elements. The XML data is then parsed on the client side using DOM parsing and then displayed. As there is no direct means of passing record sets over a cross platform network, I have used XML extensively to wrap the data in a record set. Images are retrieved as a byte array which is converted as a string and passed over the network.
A total of 35 web services were used to expose the business logic to the client.
3.6 Ajax
Ajax, shorthand for Asynchronous JavaScript and XML, is a web development technique for creating interactive web applications. The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user makes a change. This is meant to increase the web page's interactivity, speed, and usability. It makes use of the XmlHttpRequest object to make asynchronous requests to the server without the knowledge of the user. The data retrieved is then parsed using DOM and JavaScript. Ajax can only be used for transferring small amounts of data as it affects the response of the page. I have used Ajax for retrieving the city and state information and to check the email availability for the registration module, the shopping cart, check out and personalized home modules.
3.7 JavaScript / DOM
JavaScript is used for client side validation and to handle the data from the Ajax server pages. DOM provides an object oriented application programming interface that allows parsing HTML or XML into a well defined tree structure and operating on its contents. The DOM is used extensively in the shopping cart module to update the shopping cart and add buttons to remove and update the product in the cart.
3.8 Scriptaculous 1.6.1
1.1 does not have support for built in draggable contents. So I had to use Scriptaculous JavaScript library to achieve the drag drop effects in the shopping cart module of the website. It is built on the Prototype JavaScript framework. Its development is driven heavily by the Ruby on Rails framework, but it can be used in any environment. It is a JavaScript library which has inbuilt functions for various effects, for example the blinds effect which makes the contents of a ‘div’ slowly appear and disappear.
3.9 RSS 1.0
RSS which stands for Really Simple Syndication is a standard for publishing regular updates to a web based system. It can be used for syndicating news and the content of news-like sites, recent changes" page of a wiki, a changelog of CVS checkins, even the revision history of a book. This project uses RSS feeds to know about the deals in various websites and let the users have their personalized view of the feeds. The basic format of an RSS feed has the structure of XML and it has a specific format.
[pic]
Figure 5: Format of RSS feed [4]
The above RSS feed is taken from DHTML goodies. RSS feeds have the above structure and the tags are not customizable unlike XML. Each RSS feed has a single channel which has a number of items which are links to other web pages. Each item has a publication date which allows the items to be sorted so that the latest item is displayed first in the field. 1.1 does not have support for web parts which are built for RSS feeds. Hence I had to use the JavaScript framework from DHTML goodies website. I had to write an RSS parser for parsing the feed and display them in RSS boxes. The items are sorted according to their publication date and then displayed. The publication date format of an RSS feed is RFC 1123 which is not supported by 1.1, so I had to parse it as a string and convert it into a date.
IMPLEMENTATION
The implementation part of the project is concerned with interoperability and primarily focuses on the feasibility question of the report. i.e., if a company has the business logic in J2EE, how easy is it to give it a presentation layer in a different platform. A fully functional E-Commerce website which has a heterogeneous architecture (Figure 6) is developed for this purpose. The testing part of the project answers how well this architecture works in comparison with a homogeneous architecture.
4.1. System Architecture
The architecture of the cross platform website is shown below
[pic]
Figure 6: System Architecture
The client can either contact the server by calling a C# function on the code behind file (aspx.cs) causing a request to be sent to the server or contact the server asynchronously using Ajax. The code behind file and the Ajax server pages call the corresponding web service which resides on the WebLogic application server. The browser can also contact the web service directly using Ajax. The web service in turn calls a function in the session bean which interacts with the database using JDBC. The session bean sends a request to the SMTP server to send emails. The component of the .NET framework does not play any significant part as the business logic is entirely handled by the EJB’s.
2 Use Case Diagram
The use case diagram from the customer’s perspective is shown below. The customer can register and then login to the website. He can browse through various items and apply filters, search for a product, sort the results and select items to buy. He can also browse through previous transactions and create his own home page using RSS feeds.
[pic]
Figure 7: Customer Use case diagram
The use case diagram from the system’s perspective is shown below. The system can authenticate a user when he tries to logon to the website. It can validate the credit card number entered by the user and encrypt the password and store it in the database. It can check for user name conflicts while a user is registering to the website and send email to the user if he forgets his password.
The system also calculates the shipping cost based on the total price of the items purchased and the tax based on the zip code.
[pic]
Figure 8: System use case diagram
4.3 Class Diagram
The customer class is the cardinal class giving details about the customer and what actions he can perform. A customer is associated to one credit card and a credit card has only one customer. A shopping cart contains 1 or more items while an item may appear in more than a shopping cart. A customer can be associated with more than 1 shopping cart but a shopping cart is associated with only 1 customer. Every transaction has a single shopping cart and a shopping cart may or may not be in a transaction. Since the customer may add items to the shopping cart but may not check them out.
[pic]
Figure 9: Class diagram
4.4 Database Design
[pic]
Figure 10: Database Relational Schema
I have used the Oracle 9i server of the department of CIS as the database server for this project. I have used 11 tables to build the resource tier of the website. The information about the main categories like men’s, women’s, kid’s, and accessories is stored in msr_category. Each category has subcategories like Men’s running or Women’s tops which are stored in msr_subcategory with a unique subcategory id. Every product is stored in the table msr_items which gives the details of the product like brand, color, size, and subcategory. Every product has three images (small, medium, and large) which are stored in msr_subcat_image as blobs. The details of the customer are stored in msr_customer_details and the credit card details are stored in msr_customer_card. The table msr_shoppingcart captures the information related to a shopping cart like the items and their quantity in the cart. If the customer purchases the items the transaction is recorded in the table msr_transaction. The table msr_personalizedhome keeps track of the RSS feeds the user has selected for his homepage. The tbl_zipcodes contains the zip codes of 44,000 towns and cities in the United States. This is used to retrieve the city and state information based on the zip code.
Apart from these tables I have used the following PL/SQL procedures embedded in packages.
a) PKG_ITEMS contains
1. get_items: This procedure retrieves the products and their details based on the brand, size, and color.
2. get_filters: This procedure retrieves the filters based on the subcategory id. For example, it retrieves all the brands that are related to men’s running shoes.
3. get_product_details: Retrieves the product details based on the product id.
4. get_new_arrivals: This procedure retrieves the new arrivals based on the arrival date and information like brand and subcategory.
5. get_max20sellers: Retrieved the top 20 selling items on the website. It utilizes the view view_sales to retrieve this information.
b) PKG_PERSONALIZEDVIEW contains
1. insertfeed: This procedure inserts RSS feeds based on the username into the table
msr_personalized_home.
4.5 Web Services
The following is the list of web services that are used to expose the business logic written in EJB’s for this website.
1. Registration web service:
This web service provides the interface to the registration functionality and exposes the functions like authenticating the user, checking email availability, retrieving the city and state information from zip code, inserting the user details in the database, and retrieving the user details.
2. Shopping cart web service:
This web service provides the interface to the shopping cart functionality and exposes the functions like adding, removing, updating items to shopping cart, calculating taxes and shipping cost, retrieving cart details, selecting the maximum sellers, and retrieving details about new arrivals.
3. Personalized home web service:
This web service provides the interface to the personalized home functionality and exposes the functions like retrieving feeds based on email, inserting feeds into the database, and updating the feeds.
4. Banner web service:
This web service provides the interface to miscellaneous functionalities of the web site like retrieving product details, retrieving filter information, retrieving banner details and other functions that are used to populate the menu bar.
Other web services include validating the credit card and resetting the password and notification by email.
4.6 Functionality
BigBazaar is an online shopping website which includes the basic features that are required by an E-Commerce website. The functions which require interaction with the databases are written in EJB’s which are exposed as web services that the IIS server uses to fulfill the users request.
4.6.1 Registration: Customers can register on the website using an Ajax equipped form by providing details like name, address, and login information. The city and state information is automatically fetched from the database upon providing the zip code by sending an asynchronous request to the server. The server in turn calls the corresponding web service which returns the city and state information to the server which populates the textboxes using JavaScript. Customers provide their login username which is an email address and a password. The username is checked for uniqueness in the database asynchronously as he enters the information. If the username provided already exists in the database the user is notified and if the user name does not exist, a new account is created with that username and the password is stored in an encrypted format in the database. The customers are also required to provide the credit card details which are validated using the mod 10 algorithm.
4.6.2 Login and shop: After registering to the website customers can login by providing their email and password and start shopping after a successful authentication.
4.6.3: Browse items: Customers can browse various items based on the category. For example, the store assorts the items into categories like men’s apparel, women’s footwear, accessories etc.
Customers can also browse by best selling items and new arrivals.
4.6.4 Search, Sort and filter items: Customers can search for a particular item by its name or by its brand. They can sort items by their price and filter the displayed items by brand, color, size, or price. These filters are dynamically populated from the database.
4.6.5 Shopping Cart: If the customer is interested in a particular item he can add it to the shopping cart by simply dragging its image onto the shopping cart which is below the displayed item. The shopping cart is updated with the new item and provides the options of editing the quantity and removing the item completely. All these operations are performed asynchronously using the Ajax technology along with DOM and XML. The backend logic is handled using EJB’s. The user can navigate away from the page and select other items to add to the cart. After the user is done with selecting items he can check them out.
4.6.6 Check Out: The check out phase comprises of tax calculation and shipping cost for the items in the cart. These are then added to the total cost of the items and displayed. The user can still edit his shopping cart and the calculations are done asynchronously. The user can edit his shipping address information and the shipping method at this stage and confirm the order to complete the transaction.
4.6.7 View transaction history: Customers can view their past orders using this functionality
4.6.8 Personalized home: This is a replica of Google’s personalized home. After logging in, the customers can use this feature to add RSS feeds to their page which will enable them to access deals other related websites and other interesting feeds of their own. Each user has his/her own personalized view. Any changes to this view like adding feeds or changing the positions of the displayed feeds are reflected in the database. So when the user logs back in, the view of his homepage is persisted.
4.6.9. Locate a store: This feature which utilizes the Google map API can be used to locate the stores in a particular city or town.
4.6.10: Reset password: Customers have an option of resetting their password if they have forgotten it.
INTEROPERABILITY, A PROGRAMMER’S PERSPECTIVE
This chapter deals with the issues that could occur while designing a cross platform based web site from a programmer’s perspective, assuming that the programmer is proficient in both the technologies. The entire business logic has to be exposed as web services so that the .net client can access the functionality of the web site. As the underlying platforms are different, a number of issues can arise while trying to make them communicate and pass data between them.
1. Inability of web services to return complex data types. Since web services are platform independent they can only return basic data types like Integer, Boolean and String. These data types are uniform across both the platforms. However data types like record set (J2EE) and data set (.NET) are frequently used while retrieving data from the database. After retrieving the data as a record set a programmer needs to convert the record set into xml string in the code and return the output as a string. Java does not have a method of converting the record set into a string. The string returned from the web service has to be parsed on the client side to retrieve the database values.
2. User defined XML tags. The popularity of XML is due to its user defined custom tags. However, in the case of interoperability they pose a problem. For example, the EJB retrieving the price and name of an item may embed these retrieved values in custom tags like ‘’ and ‘’ when constructing the XML string. Now, to parse the XML string on the client side, the developer must know how the values are embedded i.e., he should know that price is embedded in ‘’ tag. Here the abstraction provided by the web service is lost as the WSDL file is of no use. The WSDL file only talks about the parameters, their type which are to be passed to the web service, and the type of the returned data which is string in this case.
3. Change in Business Logic: The original business logic in J2EE may return result sets to the corresponding JSP client (presentation layer). But when the presentation layer is changed to .NET the business logic has to be modified slightly to return strings instead of record sets. Functions that return basic data types need not be modified and can be exposed as web services.
4. Passing parameters. In the validation module, I had to pass a character value from the .net client to the web service. However while retrieving the data at the EJB’s this character is being interpreted as an integer. The reason for this is web services use ASCII encoding of characters by default.
5. Use of a suitable IDE: I have used WebLogic IDE for coding the business logic which has advanced features like automatic creation of entity beans, creation of web services, generating WSDL file, automatic deployment of EJB’s and web services. If the business logic is written in a not so advanced IDE, exposing the EJB’s as web services would have been difficult as a number of steps are involved in this process. Fortunately, we have a number of advanced IDE’s like WebLogic, NetBeans, IBM’s WebSphere which abstract the deployment issues from the coding
To summarize, the easiness in exposing the business logic depends on the complexity of the EJB’s, the IDE that is being used and the programmer’s proficiency. The advanced tools have really made creating heterogeneous web sites simple and fast.
TESTING
Testing was performed on the same system which hosts the two web servers, IIS and WebLogic. The database was accessed using wireless LAN. The configuration of the system is shown below.
Table 1: Configuration of System
|Operating System |Windows XP Professional |
|Processor |Intel Pentium(M) |
|Memory |1 GB RAM |
|Clock Speed |1.86 GHz |
6.1 Unit Testing
The functionality of the website depends upon the correctness of the web services in responding to the requests with a suitable and legitimate response. So in order to check the functionality of the website black box testing of the web services is needed. The web services could either be tested at the WebLogic application server using JUnit or at the .Net Client using NUnit. Checking the correctness from the client is more accurate as these services are invoked from the client. This would also check the cross platform compatibility. Hence, I have used NUnit to test the web services. A total of 19 functions were checked for correctness and all of them were found to be responding correctly.
1. AuthenticationTest : This test case tests the web service that takes the username and password as input and verifies the authenticity of the user.
2. CardDetailsTest: The web service which returns the credit card details when the username is provided is tested
3. EmailAvailabilityTest: This test case tests the web service which checks the database for similar emailget2MaxSellersTest: This test case checks the web service that returns the maximum sellers from the database.
4. getCartDetailsTest: This test case tests the web service that returns the cart details if the cart number is provided.
5. getItemsbyFiltersTest: This test case tests the web service that returns the items based on the filters like brand name, price range etc.
6. getShippinTaxesTest: This test case tests the web service that returns the shipping and taxes information based on the total value of the shopping cart.
7. insertProductIntoCartTest: This test case tests the web service which inserts the product into a shopping cart.
8. insertTransactionTest: This test case tests the web service which inserts the transaction, into the database.
9. Retrieving information tests: Various tests were conducted to test the web services that retrieve information from the database. These include retrieving category name, zip code, filter information, brand information, user details, banner information etc.
10. validatingCreditCardTest: This test case is used to test the web service which validates the credit card information provided.
[pic]
Figure 11: Snapshot of NUnit testing
6.2 Performance Testing
As discussed earlier, the choice between migration and interoperability boils down to the performance of the web server in responding to the requests. For testing interoperability I have used the architecture of the BigBazaar website as a framework. To test the migration option I have replaced the web service calls to J2EE with calls to making the architecture homogeneous.
Testing tools:
▪ Apache JMeter: I have used Apache JMeter to perform load testing for most of the test suites. Its simple GUI and elaborative aggregate report make it an effective testing tool.
▪ Microsoft Application Center Test: Since Apache JMeter does not support testing of pages with Ajax I tried to use Microsoft ACT for some test suites.
▪ AdventNet QEngine: QEngine is an advanced tool for functional, performance and web service testing of web applications and web services. I used QEngine for testing the Ajax pages.
Test Suite design. I have designed 9 test suites to simulate various real time scenarios that could occur. Every test suite tests both architectures rigorously by varying the parameters of server load, request length and complexity of the request and finding out the page download time (ms). The load on the server is varied from 1 browser making 200 requests each to 10 browsers making 200 requests each. Since the IIS server supports only 10 simultaneous browser connections, the number of browsers was restricted to 10 to minimize the socket errors. I have designed 2 pages for each test suite, one that has homogeneous architecture and the other that has heterogeneous architecture. Each test suite is run for 4 iterations and the mean values of the page download time are calculated. The architecture of the 2 pages is shown below. I will refer to the pages as homogeneous page and heterogeneous page.
[pic]
Figure 12: Control flow of heterogeneous page
[pic]
Figure 13: Control flow of homogeneous page
Summary of the test results
The following table displays the mean page download time in milliseconds for all the test suites.
Table 2: Summary of test results
[pic]
[pic]
Figure 12: Graphical view of the performance under heavy load
We can infer from the table that the performance of the heterogeneous pages is slower when compared to the homogeneous pages. The homogeneous pages are less than twice as fast as the heterogeneous pages while retrieving data from the database in the first three suites and nearly 10 times faster in the suites 5, 6, and 7. The homogeneous pages are thrice as fast as the heterogeneous pages in the 4th test suite. The performance of both the pages is almost equal in the 8th test suite while the homogeneous pages are 5 times faster than their counterparts in the last suite. A closer look at the test suites will enable us to determine the cause of this low performance.
Test Suites 1, 2, and 3
These test suites were designed for testing normal pages that retrieve varying amounts of data like 50KB, 200KB, and 1MB from the database. The tests are performed on two pages, one that gets data through a J2EE web service and another which gets the same data through . The homogeneous page has the bottle neck of accessing the database while the heterogeneous page has the bottleneck of accessing the database and returning the result to a different platform. Since the same data is retrieved in both the pages, we would also be testing the performance of in accessing the database vis-à-vis JDBC accessing the database.
Analysis for the above test suites:
In test suites 1, 2, and 3, the responsiveness of the heterogeneous pages is not far behind the homogeneous pages. The overhead of the database access is equal on both the pages and there is neither wrapping of xml data on the J2EE side, nor parsing of xml data on the client side, thereby reducing the interoperability overhead. The low interoperability overhead makes both the architectures equally responsive.
Test Suite 4
This suite was designed to test the scenario where heavy computation is done in the business logic. One thousand numbers are retrieved from the database and we sort them using bubble sort and then find the square root of the sum of the cosine’s, sin’s and log values of all the thousand numbers and return the result.
Analysis of test suite 4:
The homogeneous pages were only thrice as fast as the heterogeneous pages in this case. This can be attributed to the identical work done by both and EJB’s. There is no xml wrapping overhead on the EJB’s which makes the heterogeneous pages more responsive.
Test Suite 5
This suite is designed to test pages that retrieve data with very little logic overhead on the database. These are pages that retrieve a name when an email is provided. The purpose of the test is to minimize the overhead on the database so that the actual interoperability overhead can be calculated. The homogeneous page will certainly perform better than the heterogeneous page, but the real purpose is to test the tolerability of the heterogeneous page.
Test Suite 6
This suite is designed to test pages that retrieve data with complex logic on the database. A procedure which retrieves items based on the filters passed is used to generate the complexity. This test analyses the ability of a heterogeneous website to handle the complexity. The weight of each response is 19 KB.
Test Suite 7
This suite is designed to test pages that retrieve large amount of data (1000 records, 300 KB) from the database. It differs from suite 3 in that it converts the data into xml format and passes it to the client. The client parses the huge xml string and loads them into a table.
Analysis of test suites 5, 6, and 7:
On the average, the homogeneous architecture is 20 times faster than the heterogeneous architecture in these test suites. This is due to the fact that a heterogeneous page has an additional overhead of xml wrapping and unwrapping. Data is retrieved as a record set from the database and wrapped up in xml format and passed to the client. The client then, has to parse the xml string and load the elements. The low performance of the heterogeneous page can be attributed to this overhead of xml wrapping/unwrapping.
Test Suite 8
This test is designed to check the response of Ajax equipped pages when retrieving small amounts of data on both platforms. The Ajax overhead should not be considered as it is equally significant in both homogeneous architecture and heterogeneous architecture.
Test Suite 9
This test is designed to check the response of the Ajax equipped pages when retrieving large amount of data.
Analysis of test suites 8 and 9:
Test suite 7, which is tested for small amounts of data surprisingly went well for the heterogeneous page. The response time was on par with its counterpart, especially for heavy loads. However when large amount of data is passed the page lags behind in performance. Since Ajax is generally used to transfer small amounts of data, the heterogeneous architecture will work fine for such pages.
Overall analysis
The following table gives the number of times the homogeneous page if faster than the heterogeneous pages.
Table 3: Overall analysis of the test suites
[pic]
From the above table we can infer that for file transfers both heterogeneous and homogeneous architectures perform equally well, and the difference in the performance of both decreases as the size of the file increases. This may be due to the fact that DataAdapter in 1.1 is not optimized to handle large number of records. This drawback was addressed in the latest version of 2.0.
The performance of a heterogeneous architecture is lower than the homogeneous architecture when large amounts of data are retrieved from the database due to the additional overhead of wrapping the data in xml format. The difference in the performance decreases with increased data size due to the fact that the homogeneous platform gets the data from the database in a DataAdapter which is not optimized for performance. However, we cannot conclude that heterogeneous pages are poor in performance since the server tested is not a powerful one and more number of simultaneous browser connections is required.
An important point to note is that both the web servers reside on the same machine. So for the cross platform testing there is no real network bottleneck. A real time scenario testing is required to really predict the performance of the web service as opposed to the similar platform business logic.
EXPERIENCES AND PROJECT METRICS
7.1 Problems faced
The main hurdle for this project was the learning curve of J2EE and the WebLogic IDE. As this is my first application in J2EE I had to learn about EJB’s and how they are developed in WebLogic. I had to go through all the tutorials in WebLogic on Entity beans, Session beans and Web services. As I was using 1.1 which does not have support for Ajax or dragdrop elements, I had to rely on third party tools like Scriptaculous and code from DHTML goodies. Though I had the framework from DHTML goodies, the RSS parser was in PHP. I had to customize the JavaScript and then write a parser in .net for RSS. The date format was encoded in RFC1123 format which is not supported for parsing in .net. So I had to extract the date information from the string by parsing it manually. Frequently getting disconnected to oracle server was also a major problem. I used to get a lot of TNS time out errors while implementing the project. I had tried various tools for testing this website. JMeter could not test Ajax pages, so I had to look for an alternative. I have tried Microsoft ACT but was getting socket errors while testing heavy loads. So I had to use AdventNet’s QEngine to do Ajax testing. I had to run the tests many times to get a valid result as some of them resulted in socket errors and HTTP errors. Often JMeter used to choke and shutdown while testing heavy load applications.
7.2 Overall Experience
This project gave me an insight into the development of a cross platform based website and exposed me to the J2EE architecture for the first time. Working with EJB’s, especially the entity beans was a challenging task. The drag drop effects by the Scriptaculous framework held me in awe of the power of JavaScript and the plethora of things it can do along with DOM. I got to know the working of RSS feeds and their use in day to day life. Implementing the replica of Google’s personalized home appeased my thirst for achievement. Courtesy of the rigorous testing of the website, I realized that interoperability is fruitful in cases of file transfers from the database and tolerable in case of normal data transfer. To summarize, doing this project was a very good learning experience and made me realize how well people come up with ideas to tackle issues which were once a major concern.
7.3 Project metrics
Lines of Code
Table 4: Lines of code/ number of classes
| User controls |1600 / 17 |
| Code Behind files |4000 / 12 |
|EJB’s |3000 / 10 |
|Web Services |400 / 5 |
|JavaScript |1041 |
Time spent
Table 5: Time spent on the project
|System setup and installation |3 hrs |
|Learning WebLogic IDE |12-15 hrs |
|Implementation |65-80 hrs |
|Testing |30-40 hrs |
|Documentation |10-15 hrs |
CONCLUSION AND FUTURE WORK
8.1 Conclusion
The objective of the project was to determine the feasibility in accessing the business logic in J2EE from an platform and then test the performance of a heterogeneous architecture vis-à-vis a homogeneous architecture. This would enable us in choosing the right choice between migration and interoperability. From a programmer’s perspective interoperability doesn’t seem to be any complex than migration just because of the advanced IDE’s that are provided today. It all boils down to how the server performs in both architectures when subjected to heavy load.
The performance of the heterogeneous architecture is impressive in some cases like file transfers. It is on par with the performance of the homogeneous architecture as the file size increases. However, the heterogeneous architecture lags behind when large amounts of data is to be passed due to the additional overhead of xml wrapping. The report provides the results of various tests that simulate situations that could occur in real world and the choice between migration and interoperability really depends on the complexity of the application and what it does.
8.2 Future work
The following are some of the enhancements that could be made in the future.
8.2.1 Implementation
▪ Customers can have the option of reviewing the products and the products can be rated by the feedback.
▪ Customers can have the option of choosing multiple credit cards from a single user account.
▪ Every product can be classified by a style number and customers should be able to search by the style number.
8.2.3 Testing
▪ Both the servers should have a communication bottleneck between them to match up with the real time scenario.
▪ The load on the server can be increased drastically up to 200 simultaneous browser connections to simulate real time scenarios and the performance of both the architectures should be monitored.
▪ The testing should be carried on powerful servers that are used by organizations for their applications. The results of the tests would be similar to real time performance of their applications.
REFERENCES
1] Simon Guest, “ and J2EE Interoperability toolkit”, 2003
2] Scott Short, “ Building XML Web services for the Microsoft platform”, 2002
3] David Muldrow, Understanding Web Service Invocations. April 2002
4] DHTML Goodies, Draggable RSS boxes,
5] Scriptaculous, Java Script Effects,
6] BEA Web Logic Workshop Help, Documentation, .
7] Jonathan Fenocchi, How to develop web applications with Ajax, Pt.1, March 2003,
8] DOM tutorial, DOM nodes and trees, June 2006
9] Mondial Database, Zip codes database,
10] , Introducing the XmlDocument Object, Oct 2004
11] Finishline, User Interface and functionality,
.
-----------------------
Presentation Tier
Database/ Message Queues
STRUTS
JSP’s
Web
Services
XML Beans
Local/ Remote
Stateless Session EJB’s
Message Driven Beans
J
M
X
Services Tier
JDBC
Row Sets
JMS
Java Mail
Local CMP
Entity Beans
Integration Tier
WebLogic/J2EE Component
Open Source/ 3rd Party Component
user session
user activity
BROWSER
Code behind
IIS 5.0 WEB SERVER
EJB’S
Web
Services
WebLogic
APPL SERVER
CIS
Oracle 9i
Database
KSU
SMTP
Server
Web Service call
Front
End
HTML
CSS
Ajax server pages
AJAX
function call
Web Service call
JDBC
AJAX
function call
Browser
Code
Behind
CIS Oracle Database
1
8
Web Service
EJB’s
2
7
3
6
4
5
IIS Server
WebLogic
Server
Ajax
4
Browser
Code
Behind
CIS Oracle Database
1
6
2
3
5
Ajax
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.