ABSTRACT .edu



1. INTRODUCTION

This section introduces the idea of a cross-platform component based ecommerce framework and the advantages the above framework has over a system with identical client and server technologies. This latter sections talk about the technologies involved in developing such a frame work and also present an architecture that implements this framework.

A cross-platform component based approach for an ecommerce framework holds many advantages. It allows enterprise developers to use business components developed by a third party to be integrated into their web application eliminating the time and energy involved in developing and testing the components themselves. As these business components are a major source of revenue for the organization developing them, the components are sure to work well under adverse conditions. Integrating third party business components involves using an architecture that

• Is based on open standards

• Is platform and language independent

• Emphasizes on a mode of communication understandable to both systems

Web Services form an ideal choice for such an architecture as they are utilize XML, they are based on open standards like SOAP, WSDL and UDDI, and use HTTP ,which is understood

by many systems as the underlying transport mechanism. As a part of the study an architecture was designed and implemented that connected J2EE and Microsoft .NET (they being current and popular enterprise technologies) using web services. The architecture involved developing a web based shopping portal in .NET where generic functionalities were developed as third-party business components in EJB and plugged into the .NET web application. This represents a realistic scenario as many ecommerce applications need to implement functionalities that are common and found across the entire spectrum of applications. Such generic functionalities can be implemented as components and plugged into the web application as and when needed across platforms and across applications. EJB’s are ideally suited for developing secure, transactional, scalable and robust components.

Advantages of a Cross-Platform Approach

a. Reduces software development lifecycle

b. Eliminates time spent in testing and debugging the application

c. Decreases “Time-to-Market” aspect of the web application

2. CROSS-PLATFORM INTEGRATION: KEY TECHNOLOGIES INVOLVED

2.1 Java 2 Enterprise Edition (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.

It's important for realize that J2EE is a standard, not a product. J2EE describes agreements between applications and the containers in which they run. So long as both sides obey the J2EE contracts, applications can be deployed in a variety of container environments. The J2EE camp's goal is to give customers choice of vendor products and tools, and to encourage best-of-breed products to emerge through competition.

Java: The foundation for J2EE

The J2EE architecture is based on the Java programming language. What's exciting about Java is that it enables organizations to write their code once, and deploy that code onto any platform. J2EE is an application of Java. Your J2EE components are transformed into byte code and executed by a JRE at runtime. Even the containers are typically written in Java. Additionally, J2EE provides techniques for managing data persistence by allowing data to be persisted by the bean developer or by the container. These technologies are called Bean – Managed Persistence (BMP) and Container – Managed Persistence (CMP). Each has their own advantaged and disadvantages and can be applied beneficially to specific problems. J2EE also provides powerful state management facilities through the use of its Session Beans.

J2EE and Web Services

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 recently 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. J2EE web services development model is shown in Fig 1.

[pic]

Fig 1: J2EE Architecture [1]

J2EE application is hosted within a container, which provides qualities of service necessary for

enterprise applications, such as transactions, security, and persistence services. The business layer performs business processing and data logic. In large-scale J2EE applications, business logic is built using Enterprise Java Beans (EJB) components. This layer performs business

processing and data logic. It connects to databases using Java Database Connectivity (JDBC) or SQL/J, or existing systems using the Java Connector Architecture (JCA). It can also connect to business partners using web services technologies (SOAP, UDDI, WSDL, ebXML) through the Java APIs for XML (the JAX APIs). Business partners can connect with J2EE applications through web services technologies (SOAP, UDDI, WSDL, ebXML). A servlet, which is a request/response oriented Java object, can accept web service requests from business partners. The servlet uses the JAX APIs to perform web services operations. Shared context services will be standardized in the future through shared context standards that will be included with J2EE.

Traditional 'thick' clients such as applets or applications connect directly to the EJB layer through the Internet Inter-ORB Protocol (IIOP) rather than web services, since generally the thick clients are written by the same organization that authored J2EE application, and therefore there is no need for XML-based web service collaboration.

Web browsers and wireless devices connect to Java Server Pages (JSPs), which render user interfaces in HTML, XHTML, or WML.

2.2 Microsoft .NET

8 is product suite that enables organizations to build smart, enterprise-class web services. Note the important difference: .NET is a product strategy, whereas J2EE is a standard to which products are written. is largely a rewrite of Windows DNA, which was Microsoft's previous platform for developing enterprise applications. The new .NET Framework replaces these technologies, and includes a web services layer as well as improved language support. The developer model for building web services with is shown in Fig 2

[pic]

Fig 2: Microsoft .NET architecture [1]

The .NET application is hosted within a container, which provides qualities of service necessary for enterprise applications, such as transactions, security, and messaging services. The business layer of the .NET application is built using .NET managed components. This layer

performs business processing and data logic. It connects to databases using Active Data Objects

() and existing systems using services provided by Microsoft Host Integration Server 2000, such as the COM Transaction Integrator (COM TI). It can also connect to business partners using web services technologies (SOAP, UDDI, and WSDL). Business partners can connect with the .NET application through web services technologies (SOAP, UDDI, WSDL, and BizTalk). Traditional 'thick' clients, web browsers, wireless devices connect to Active Server Pages () which render user interfaces in HTML, XHTML, or WML. Heavyweight user interfaces are built using Windows Forms.

The .NET Framework

offers language-independence and language-interoperability. This is one of the most intriguing and fundamental aspects of the .NET platform. A single .NET component can be written, for example, partially in , the .NET version of Visual Basic, and C#, Microsoft’s new object oriented programming language. How does this work? First, source code is translated into Microsoft Intermediate Language, sometimes-abbreviated MSIL, sometimes IL. This IL code is language-neutral, and is analogous to Java byte code. The IL code then needs to be interpreted and translated into a native executable. The .NET Framework includes the Common Language Runtime (CLR), analogous to the Java Runtime Environment (JRE),

which achieves this goal. The CLR is Microsoft’s intermediary between .NET developers’ source code and the underlying hardware, and all .NET code ultimately runs within the CLR.

This CLR provides many exciting features not available in earlier versions of Windows DNA, such as automatic garbage collection, exception handling, cross-language inheritance, debugging, and “side-by-side” execution of different versions of the same .NET component.

Understanding J2EE and .NET by analogy

|FEATURE |J2EE |Microsoft .NET |

|Type of Technology |Standard |Product |

|Interpreter |JRE |CLR |

|Dynamic Web Pages |JSP |ASP .NET |

|Middle Tier Components |EJB’s |.NET managed components |

|Database Access |JDBC, SQL/J |ADO .NET |

|SOAP, WSDL, UDDI |Yes |Yes |

|Implicit Middleware |Yes |Yes |

To help you understand both models, we offer analogies between J2EE and .NET technologies in Table 1 [1]

3. WEB SERVICES

Thus section discusses the concepts of web services and the typical characteristics they embody. The key technologies under the web service rubric are discussed and the notion of a Service Oriented Architecture (SOA) on which web services is based is introduced.

3.1 Background

Web services are components that implement business logic via services and expose

these services programmatically over the web, which could be invoked by service clients

using SOAP over HTTP. Web services provide the language and platform independence by separating the specification from implementation and provide the loosely coupled integration between applications by message-based, synchronous or asynchronous communication. Web

services are based on decentralized architecture wherein there is no central server and

communication is over internet using standard protocols. Protocols do not make any

assumption on the underlying implementation. One of the important features of the Web services based computing model is that both clients and Web services are unaware of the implementation details of each other. The Web services infrastructure provides several components that enable client applications to locate and consume Web services dynamically. The promise of web services is to enable a distributed environment in which any number of applications, or application components, can interoperate seamlessly among and between organizations in a platform-neutral, language-neutral fashion. This interoperation brings heterogeneity to the world of distributed computing once and for all. A web service is a piece of business logic, located somewhere on the Internet, that is accessible through standard-based Internet protocols such as HTTP or SMTP. Using a web service could be as simple as logging into a site or as complex as facilitating a multi-organization business negotiation. Given this definition, several technologies used in recent years could have been classified as web service technology, but were not. These technologies include win32 technologies, J2EE, CORBA, and CGI scripting. The major difference between these technologies and the new breed of technology that are labeled as web services is their standardization. This new breed of technology is based on standardized XML (as opposed to a proprietary binary standard) and supported globally by most major technology firms. XML provides a language-neutral way for representing data, and the global corporate support ensures that every major new software technology will have a web services strategy within the next couple years. When combined, the software integration and interoperability possibilities for software programs leveraging the web services model are staggering. A web service has special behavioral characteristics:

XML Based

By using XML as the data representation layer for all web services protocols and technologies that are created, these technologies can be interoperable at their core level. As a data transport, XML eliminates any networking, operating system, or platform binding that a protocol has.

Loosely Coupled

A consumer of a web service is not tied to that web service directly; the web service interface can change over time without compromising the client's ability to interact with the service. A tightly coupled system implies that the client and server logic are closely tied to one another, implying that if one interface changes, the other must also be updated. Adopting a loosely coupled architecture tends to make software systems more manageable and allows simpler integration between different systems.

Coarse Grained

Object-oriented technologies such as Java expose their services through individual methods. An individual method is too fine an operation to provide any useful capability at a corporate level. Building a Java program from scratch requires the creation of several fine-grained methods that are then composed into a coarse-grained service that is consumed by either a client or another service. Businesses and the interfaces that they expose should be coarse-grained. Web services technology provides a natural way of defining coarse-grained services that access the right amount of business logic.

Ability to be synchronous or asynchronous

Synchronicity refers to the binding of the client to the execution of the service. In synchronous invocations, the client blocks and waits for the service to complete its operation before continuing. Asynchronous operations allow a client to invoke a service and then execute other functions. Asynchronous clients retrieve their result at a later point in time, while synchronous clients receive their result when the service has completed. Asynchronous capability is a key factor in enabling loosely coupled systems.

• Supports Remote Procedure Calls (RPCs)

Web services allow clients to invoke procedures, functions, and methods on remote objects using an XML-based protocol. Remote procedures expose input and output parameters that a web service must support. Component development through Enterprise JavaBeans (EJB’s) and .NET Components has increasingly become a part of architectures and enterprise deployments over the past couple of years. Both technologies are distributed and accessible through a variety of RPC mechanisms. A web service supports RPC by providing services of its own, equivalent to those of a traditional component, or by translating incoming invocations into an invocation of a EJB or a .NET component.

Supports document exchange

One of the key advantages of XML is its generic way of representing not only data, but also complex documents. These documents can be simple, such as when representing a current address, or they can be complex, representing an entire book or RFQ. Web services support the transparent exchange of documents to facilitate business integration

3.2 Major Web Services Technologies

Several technologies have been introduced under the web service rubric and many more will be introduced in coming years. The web service paradigm has grown at such a breakneck speed that several competing technologies are attempting to provide the same capability. However, the web service vision of seamless worldwide business integration is not feasible unless the core technologies are supported by every major software company in the world. Over the past two years, three primary technologies have emerged as worldwide standards that make up the core of today's web services technology. These technologies are:

• Simple Object Access Protocol (SOAP)

SOAP provides a standard packaging structure for transporting XML documents over a variety of standard Internet technologies, including SMTP, HTTP, and FTP. It also defines encoding and binding standards for encoding non-XML RPC invocations in XML for transport. SOAP provides a simple structure for doing RPC: document exchange. By having a standard transport mechanism, heterogeneous clients and servers can suddenly become interoperable. .NET clients can invoke EJB’s exposed through SOAP, and Java clients can invoke .NET Components exposed through SOAP.

• Web Service Description Language (WSDL)

WSDL is an XML technology that describes the interface of a web service in a standardized way. WSDL standardizes how a web service represents the input and output parameters of an invocation externally, the function's structure, the nature of the invocation (in only, in/out, etc.), and the service's protocol binding. WSDL allows disparate clients to automatically understand how to interact with a web service.

• Universal Description, Discovery, and Integration (UDDI)

UDDI provides a worldwide registry of web services for advertisement, discovery, and integration purposes. 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. UDDI provides a structure for representing businesses, business relationships, web services, specification metadata, and web service access points.

Individually, any one of these technologies is only evolutionary. Each provides a standard for the next step in the advancement of web services, their description, or their discovery. However, one of the big promises of web services is seamless, automatic business integration: a piece of software will discover access, integrate, and invoke new services from unknown companies dynamically without the need for human intervention. Dynamic integration of this nature requires the combined involvement of SOAP, WSDL, and UDDI to provide a dynamic, standard infrastructure for enabling the dynamic business of tomorrow. Combined, these technologies are revolutionary because they are the first standard technologies to offer the promise of a dynamic business. In the past, technologies provided features equivalent to SOAP, WSDL, and UDDI in other languages, but they weren't supported by every major corporation and did not have a core language as flexible as XML.

[pic]

Fig 3: Interaction between SOAP, UDDI and WSDL [2]

The relationship between these pieces (SOAP, WSDL, and UDDI) can be described as follows: an application acting in the role of a web services client needs to locate another application or a piece of business logic located somewhere on the network. The client queries a UDDI registry for the service either by name, category, identifier, or specification supported. Once located, the client obtains information about the location of a WSDL document from the UDDI registry. The WSDL document contains information about how to contact the web service and the format of request messages in XML schema. The client creates a SOAP message in accordance with the XML schema found in the WSDL and sends a request to the host (where the service is).

3.3 Service Oriented Architecture (SOA)

The Service Oriented Architecture defines a way to achieve the vision of a composite computing model using the technologies that make up the Web Services stack. A composite computing model can be defined as

“An architecture that uses a distributed, discovery-based execution environment to expose and manage a collection of service-oriented software assets.”

A software asset is nothing more than a piece of business logic; it can be a component, a queue, or a single method that performs a useful function that you decide to expose to the outside world. Like the client-server and n-tier computing models, the composite computing model represents the architectural principles for governing roles and responsibilities of its constituents. It was designed to solve a specialized group of business problems that have the following requirements:

▪ Dynamic discovery of the business logic's capabilities

▪ Separation between the description of the business logic's capabilities and its implementation

▪ The ability to quickly assemble impromptu computing communities with minimal coordinated planning efforts, installation procedures, or human intervention

In short, the "composite computing model" is the direction in which computing has headed

ever since networking became cheap and easy. Instead of trying to build larger applications on

ever larger computers, we're trying to assemble smaller components that interact with one another across many computers, and possibly thousands of miles. Instead of building a large, monolithic, proprietary inventory system, for example, we're trying to build services that access inventory databases and can easily be combined as needed. The composite computing model defines a vision for what computing should be. Service oriented architecture (SOA) represents a way to achieve this vision using the set of technologies that make up the Web Services Technology Stack. This set of technologies currently consists of SOAP, WSDL, and UDDI, though other components may be added in the future. Conceptually, the SOA model is comprised of three roles performing three fundamental interactions. The components of the SOA are web services. Each web service is made up of two parts:

Service

The implementation for a web service. A service can be as minuscule as a JavaScript

file or as elaborate as a 30-year-old, industrial-strength COBOL application running

on a mainframe. The key requirement is that it be on a network-accessible platform,

provided by the web service provider.

Service description

The interface for a web service. It is expressed in XML and is governed by one or more standards. This description includes the data types, operations, protocol bindings and network location (i.e., the URL, etc.) for the web service's implementation. Additional documents provide categorization and other metadata to facilitate discovery.

4. ALTERNATIVE TECHNOLOGIES CONSIDERED

4.1 CORBA

CORBA was considered as an alternative for cross-platform integration but was not found to be feasible after some study. With CORBA software availability is a major issue. There are only two robust implementations, Iona and Visigenic for CORBA. CORBA requires that a piece of vendor supplied middleware be installed on every node of the system. This is not feasible as business partners cannot be forced to install a piece of the vendor’s software at their site to work with their business partners. Also, the client and server objects when using CORBA communicate using a contract defined in an Interface Definition Language (IDL) which the server objects offer to the clients that invoke it. CORBA implementations come with an IDL mapping that supports many programming languages like C, C++, and Java etc. Currently, no such IDL mappings are available for the ASP .NET system which was another factor in opting for Web Services over CORBA as the choice for cross-platform component integration.

4.2 RMI and JMS

RMI and JMS are middleware technologies suitable for cross-platform integration but these technologies suffer from an inherent disadvantage. They require Java as the language of implementation. They are language dependant and hence not suited for integrating platform where the client system is based on a non-Java language.

4.3 COM/DCOM

COM and DCOM are Microsoft technologies involved in developing component based distributed systems. They were rejected as they were proprietary and dependent on Windows being used as a platform on both client and server systems.

5. WEB SERVICE INVOCATION

[pic]

Fig 4: Typical web service invocation scenario [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. Recently, most major vendors like Microsoft, IBM, BEA and other third party vendors are extending support to Web services by including SOAP toolkits. These SOAP toolkits are handling the low-level aspects of composing SOAP requests, marshalling and unmarshalling of native method calls to XML and vice-versa and by parsing the SOAP responses and by performing the data encoding, thereby hiding gory and tedious low-level details and providing abstraction to the application developers. Actual communication between clients and Web services is handled by proxy components or stubs which are compiled objects that know how to marshall native method calls to valid SOAP requests and unmarshall incoming SOAP responses to return values.

6. SOAP: THE SOUL OF WEB SERVICES

1. SOAP Fundamentals

SOAP is a specification for using XML documents as messages. The SOAP Specification contains:

▪ A syntax for defining messages as XML documents, which we refer to SOAP messages

▪ A model for exchanging SOAP messages

▪ A set of rules for representing data within SOAP messages, known as SOAP encoding

▪ A guideline for transporting SOAP messages over HTTP

▪ A convention for performing remote procedure calls (RPC) using SOAP messages

6.2 SOAP Message Exchange Model

The SOAP specification defines a model for exchanging messages. It relies on three basic concepts: messages are XML documents, they travel from a sender to a receiver, and receivers can be chained together. Working with just these three concepts, it is possible to build sophisticated systems that rely on SOAP.

6.3 XML Documents As Messages

The most fundamental concept of the SOAP model is the use of XML documents as messages. SOAP messages are XML. This provides several advantages over other messaging protocols. XML messages can be composed and read by a developer with a text editor, so it makes the debugging process much simpler than that of a complex binary protocol. As XML has achieved such widespread acceptance, there are tools to help us work with XML on most platforms. Here is an example of a SOAP Message

| |

|   |

|      |

|        Hello world! |

|      |

|   |

| |

6.4 Senders and Receivers

When SOAP messages are exchanged, there are two parties involved: a sender, and a receiver. The message moves from the sender to the receiver. This operation is the basic building block of SOAP message exchanges, the smallest unit of work. The figure below illustrates this simple operation:

[pic]

Fig 5: A Simple SOAP Operation [4]

In many cases, however, this type of operation is not enough. A more common requirement would be for messages to be exchanged in request-response pairs. As we will see later in the chapter, this is the method SOAP uses with the HTTP transport and/or the RPC convention. Requiring that model, however, would make it difficult to design one-way message exchanges. By starting with the most basic operation, a one-way message exchange from sender to receiver, more complicated exchanges can be composed without preventing the simplest exchanges from occurring. This gives us the ability to construct message chains.

6.5 SOAP Messages

Now that we have covered SOAP at a high level, let's examine the most important detail of SOAP: the structure of a message. First and foremost, SOAP uses XML syntax for messages. The structure of a SOAP message is shown overleaf:

[pic]

Fig 6: Structure of a SOAP Message [4]

The diagram shows how a SOAP message can be broken down into components. A SOAP message contains a payload, the application-specific information. Here is an example of a SOAP message as an actual XML document:

| |

|   |

|     SoapGuy@ |

|   |

|   |

|      |

|        XSLT-Man |

|      |

|   |

| |

.

6.6 SOAP Data

In order to build SOAP messages from our language of choice, we need to know how to serialize data. We need to know the rules for representing an integer, string, or floating point number in a SOAP message so that we can exchange messages freely between languages and platforms. The serialization of data inside a SOAP message is referred to as encoding.

6.7 Encoding Style

The ability to decide on a set of rules for representing data in a message is very important to the open nature of SOAP. It doesn't do much good of course to define a set of rules if we cannot tell what encoding rules were used to serialize a particular SOAP message. The encodingStyle attribute defined by the SOAP specification is used to identify the encoding rules used in a particular message.

6.8 SOAP Encoding

The SOAP Specification defines a single set of encoding rules that are referred to as SOAP encoding. SOAP encoding is based on XML Schemas and as such it closely models many of the standard types and constructs that developers would be familiar with. The value of the encodingStyle attribute for SOAP encoding is , which points to the XML Schema that defines the encoding rules.

7. APACHE EXTENSIBLE INTERACTION SYSTEM (AXIS) – A SOAP ENGINE

Axis is essentially a SOAP engine -- a framework for constructing SOAP processors such as clients, servers, gateways, etc. it also includes:

• a simple stand-alone server,

• a server which plugs into servlet engines such as Tomcat,

• extensive support for the Web Service Description Language (WSDL),

• emitter tooling that generates Java classes from WSDL.

• some sample programs, and

• a tool for monitoring TCP/IP packets.

Axis is the third generation of Apache SOAP (which began at IBM as "SOAP4J")

8. TECHNOLOGIES USED AND RATIONALE

The purpose of the project was to explore the concepts and issues involved in integrating cross –platform components into an enterprise web application through Web Services. To facilitate this process a web based shopping portal comprising of a buyer, a vendor and third party business components were developed using .NET and J2EE technologies. This section talks about the rationale behind the different technologies used. The latter sections talk about the system design and system architecture, the database schema and the kinds of performance tests the system was subjected to. Microsoft .NET and J2EE are the primary technologies that support Web Services. The motivation behind choosing these technologies was to examine their level of maturity for Web Services support and to understand the issues involved in cross-platform component integration. The shopping portal was developed in .NET while generic functionalities required of any shopping portal like calculating taxes, calculating shipping costs, and validating credit card numbers were delegated to third party EJB’s. The shopping portal was developed using the .NET technologies – ADO .NET and C# .NET. The third party EJB were based on the J2EE 1.3 specification and deployed in a J2EE compliant server. The web application runs on Windows on the .NET Framework. The web application was developed in Visual C# .NET for rapid development, client-side execution speed and responsiveness, as well as the wide availability of Windows as a client-side platform. The application server used was JBoss 3.2.3. JBoss is a J2EE based application server that is implemented in Java. It integrates with a Tomcat JSP/Servlet container. JBoss uses Java Management Extensions (JMX) for fast deployment, management and modular extensions. JMX makes it easy to integrate with additional components like Axis. Axis is an open source Apache web service framework that lets Java components to be exposed as web services. The version used for this project was Axis 1.1 which supports the SOAP 1.1 and WSDL 1.1 specifications. Axis includes a SOAP engine, a test server, tools to generate WSDL from java code, as well as Java code from WSDL. Ant 1.6.1 was used as a build tool for this project. Ant is an Apache open source framework written in pure Java. Ant build scripts are based on XML and portable across platforms. In addition to built in core tasks and additional tasks, it can be extended with custom tasks by writing Java classes. Building J2EE based web services involves many steps in the build process and Ant makes it easier to automate many of those tasks. Oracle was used as the back-end database due to its popularity in providing a robust, scalable and transactional database that had the capability to deal with binary objects and complex data types.

9. SYSTEM IMPLEMENTATION

This section provides an overview of the system, along with typical use cases, sequence diagrams and class diagrams. The database schema of the system is also presented. The use cases highlight typical scenarios of the system and the sequence diagrams model the conversations that occur between the different parts of the system. The class diagrams model the classes involved while the architecture diagrams depicts a more detailed view of the system.

9.1 System Design

The figure below Fig 11 depicts the overall architecture and the control flow within the system. The shaded ovals represent EJB’s exposed as web services.

[pic]

Fig 7: System Overview

SOAP/HTTP

Fig 8: Overview of Web Service Communication

The application consists of a buyer and a vendor. The model is distributed and loosely coupled owing to the presence of web services. The web services are generic functionalities that in the real world could be provided by third party businesses. They have been plugged into the shopping portal web application. The web services handle the communication between the .NET and J2EE systems by converting native calls to XML and vice-versa. The messages are then transported through SOAP over the HTTP protocol.

9.2 System Architecture

The figure below represents the detailed system architecture.

IIS SERVER JBOSS APPLICATION SERVER

SOAP/HTTP

Serializes the native .NET method De-serializes the SOAP Messages to

calls to XML native Java calls

Fig 9: Calls between SOAP Proxy and Web Services

The system has two main actors a buyer and a vendor. The buyer is responsible for browsing through the different categories of books available to determine the books he needs to buy. The buyer updates the cart and places the order for books. The vendor is responsible for registering the buyer with the web application and in performing the checkout process, confirming the order and generating the order invoice. The vendor part of the system has been implemented in .NET technologies and C# .NET. Once the checkout process begins the vendor invokes a call to the Java web service to determine the tax incurred for the order placed. The call is made by the vendor via a .NET proxy component. The Java web service is deployed on the JBoss application server. The .NET proxy converts the vendor invoked call to XML and constructs a SOAP payload to be transmitted via SOAP over HTTP. On the other side the Axis framework is responsible for de-serializing the XML to native Java calls which then connect with the EJB’s to perform the desired business logic. The same process is repeated when the vendor invokes the web services responsible for calculating shipping costs and validating buyer’s credit card numbers with the addition that the Shipping Web Service accesses the database at the back end to determine shipping costs. On the return journey the Axis framework composes SOAP responses which are then converted to XML and de-serialized at the vendor’s end to return values back to the vendor system.

9.3 Use Cases

[pic]

Fig 10: Buyer Use Case

The buyer use diagram depicts the function of the buyer which involve logging on to the application, viewing the catalog, adding books to the cart and checking out chosen books.

[pic]

Fig 11: Vendor Use Case

The functions of the vendor involve validating user login, validating credit card numbers, calculating tax on the books ordered, calculating shipping costs based on the buyer’s choice of shipping medium and processing the order and generating the order invoice.

9.4 Class Diagrams

The figures below depict the class diagrams used in the system. The entire web application was divided into two classes – Buyer and Vendor. The Buyer class simulated the working of a buyer in an online shopping portal. The buyer class was implemented in the .NET technologies – ASP .NET and ADO .NET.

• Buyer Module

[pic]

Fig 12: Buyer Class Diagram

The buyer classes consist of .aspx files. The buyer enters data and forwards requests to the Vendor class which then implement the request through its business logic components. The buyer module is responsible for browsing through the categories of books, adding, deleting and updating the books in the shopping cart, and logging on to the web application to begin the checkout process. The Buyer module consists of three classes:

i. Start: The Start class is the initiator class. It has four methods. The bindData() method is responsible for displaying book categories and the books available in each category. This method obtains its data from the back-end Oracle 9i database. The addCart() and viewCart() methods are responsible for adding books to the cart and viewing the current contents of the cart respectively. They do not assume anything about the identity of the user; rather the contents are stored in the session temporarily and bound to the user when he logs in. The login() method is responsible for initiating the user login.

ii. LoginUser: The LoginUser class is responsible for authenticating user login and associating a specific user with the items in his shopping cart. The loginValidation() method does the authenticating part while the addUser() method associates a specific user with items in his shopping cart

iii. ShoppingCart: The ShoppingCart class responsible for the following functions

• Adding items to the shopping cart

• Updating the quantities on the cart

• Canceling the order.

• Initiating the checkout process

• Logging out of the current session

This class assumes that the user is already logged in and is authorized to perform tasks

associated with the shopping cart.

• Vendor Module

[pic]

Fig 13: Vendor Class Diagram

The Vendor module has eight classes. It is responsible for initiating the procedures associated with checkout. It involves calculating the taxes, the shipping costs and generating the order invoice. The Vendor module is also responsible for registering users with the web application and validating the credit card number provided by users.

The individual classes are as follows:

i. TaxService: The tax accrued on books ordered is calculated by the TaxService class which is a .NET proxy class that invokes a call to an EJB which has been exposed as a web service. The TaxService class handles the responsibility of converting the .NET native call to XML and the incoming XML messages back to native .NET data. It obtains the total cost of the books in a double format and calculates the tax as a percentage of that cost.

ii. ShippingService: The ShippingService class is responsible for calculating shipping cost based on user’s choice of a shipping medium. The call is forwarded through SOAP to an EJB that is responsible for determining the shipping costs. That EJB contacts an Oracle 9i database at the backend to determine the exact cost. It expects a string value describing the user’s choice of a shipping medium and returns a double value which is the cost of using that shipping medium.

ii. CreditCardService: This web service is responsible for verifying the credit card number entered by the user. It accepts a sixteen digit credit card number to be validated using the Luhn algorithm.

iii. Order: The Order class handles the responsibility of displaying the order to the user and accepts user input regarding order confirmation. The order information contains shipping address, total cost including taxes, and the order details.

v. OrderConfirmed: The OrderConfirmed class is responsible for generating the order invoice and displaying it to the end user. The order invoice contains besides an order id, all the details that are found in the order information.

vi. RegisterCard and RegisterUser: The RegisterUser and RegisterCard classes are responsible for registering the personal user details and verifying the user’s credit card number respectively. The credit card verification is done via the CreditCardService class.

9.5 Sequence Diagrams

The sequence diagrams model conversations that occur between different components of the system. They aid in understanding intra-system component interaction.

[pic]

Fig 14: Sequence Diagram for Shipping Cost Calculation

[pic]

Fig 15: Sequence Diagram for Credit Card Validation

[pic]

Fig 16: Sequence Diagram for Tax Calculation

9.6 Database Schema

[pic]

Fig 17: Database Schema

10. USER-INTERFACE

This section talks about the user interface- the guiding principles involved in choosing a particular kind of interface and facilities available for error checking. A well-designed user-interface is essential for the success of any enterprise web application. The investment made in designing the user-interface contributes not only in keeping existing customers, but also in expanding your customer base.

10.1 Guiding Principles

• Avoid pages that are slow loading by reducing unwanted images, javascript effects.

• Have a consistent look and feel over the entire spectrum of the web application.

• Provide opportunities for users to explore the interface and learn by trial and error

• Provide a user-interface that was easy to learn and easy to use. This was accomplished by placing precise guidelines on how the user should enter the desired data.

• Provide a user-interface that was pleasing to the eye by avoiding contrasting colors and images.

2. Error Checking

Error Checking was done through validation controls provided by ASP .NET to ensure that the entered values in form fields meet the developer defined criteria.

11. SCREENSHOTS

[pic]

Fig 18: Home Page

[pic]

Fig 19: List of books available

[pic]

Fig 20: Shopping Cart contents

[pic]

Fig 21: Communicating between a .NET system and a web service

[pic]

Fig 22: Displaying order details

[pic]

Fig 23: Displaying the order invoice

12. DEVELOPMENT TIME

The project contains two modules Vendor and Buyer with three classes in the Vendor module and eight classes in the Buyer module. The development time was three months and involved writing about 5000 SLOC.

13. TESTING TECHNIQUES USED

The web application has two modules Buyer and Vendor which were independently tested. The modular nature of the web application enabled independent testing and verification of the components. The following types of tests were conducted

13.1 Functional Testing

Functional Testing was applied to both the web application and the individual web services. Test cases were developed separately for both the Buyer and Vendor modules. The test cases were developed using JUnit. Each of the web services also had their own test cases written to ensure that they produced expected outputs. Error checking was done by providing user-friendly messages to the client indicating that his request was mal-formed and providing him with directions on entering information in the correct way.

13.2 Load/Stress Testing

Stress Testing was done to analyze the performance of both the web applications and the individual web services under high loads. Apache JMeter was used for this purpose. The average response times were calculated for both the web application and the individual web services under varying load conditions.

14. PERFORMANCE EVALUATION

To test the application the credit card validation component implemented in EJB was replicated in .NET. The web application was first integrated in turn with the Java and .NET versions respectively and tested for performance. Additionally, the .NET and the Java versions of the same web service were individually tested to obtain performance data. A Compaq Presario x1000 notebook with a 1.8 GHz Centrino® processor and 512 MB RAM acted as the web server on which the application and the third-party business components were hosted.

Web Application: Windows Box, Compaq Presario x1000, 1.8 GHz Centrino®, 512 MB RAM

Components: Windows Box, Compaq Presario x1000, 1.8 GHz Centrino®, 512 MB RAM

14.1 Testing the Web Application

• No of Iterations (Vs) Response Time (20 threads)

The number of users was set at 20 and performance data was obtained for iterations varying from 10 to 60. The iterations were set at 60 as the web server could not handle a

load beyond that possibly because it being a single processor machine. Microsoft ACT

was used to test the web application.

[pic]

Fig 24: No of Iterations (Vs) Response Time (20 threads)

• No of Iterations (Vs) Response Time (40 threads)

The number of users was set at 40 with iterations varying from 10 to 60 in increments of

10.

[pic]

Fig 25: No of Iterations (Vs) Response Time (40 threads)

Theoretically the application when integrated with a .NET service should show a superior performance as it used the Document/Literal style for passing SOAP messages as opposed to a RPC/Encoded style for the Java web services. But this was not so. This might be attributed to the high CPU usage (90%), high bandwidth (1,004,419.88 bytes/sec) and increasing page fault rates which might have overshadowed the gains obtained from consuming a .NET web service.

14.2 Testing the Web Service

The web services were individually tested using Apache JMeter.

• No of Iterations (Vs) Response Time (20 threads)

The iterations were varied from 10 to 60 in steps of 10.

[pic]

Fig 26: No of Iterations (Vs) Response Time (20 threads)

• No of Iterations (Vs) Response Time (40 threads)

[pic]

Fig 27: No of Iterations (Vs) Response Time (40 threads)

The .NET Web Service had lower response times than the Java Web Service on both occasions. The CPU usage was at 75%. Though page faults occurred they were at a lower rate as compared to when the entire web application was tested. As lesser amount of resources was consumed gains from a using a .NET web service was more visible and overshadowed hardware and network issues.

15. IMPLEMENTATION ISSUES

The main hurdle faced during implementation was the lack of documentation dealing with interoperable web services. As Web Services Interoperability is in its nascent stages right now not much literature exists in this field. Many problems that arose during the project had to be resolved through experimentation and hit and trial. The setting up of projects in Visual Studio .NET took considerable time and many problem occurred that were related to unknown issues dealing with VS .NET and IIS server administration like lack of permissions to access .aspx pages. This was later found to occur due to lack of administrator access to the ASP .NET user account that IIS creates when VS .NET and the .NET framework is installed. A considerable amount of time was spent in analyzing the suitability of using Eclipse 2.1 and the Lomboz plug-in to develop EJB’s but this approach had to be discarded due to issues regarding integration of JBoss 3.2.3 with Eclipse 2.1 and Lomboz and unknown issues regarding the working XDoclet embedded within Lomboz. Due to unavailability of the ASPWEB account, both the .NET system and EJB’s exposed as web services were implemented on the same machine. This might have caused the web application to run faster than one might run in a real world distributed system where network issues might have hampered performance to a slight degree and introduced a margin of error. Also, during the time of implementation the Web Service specifications allowed only Stateless Session beans to be exposed as web services. This prevented CMP’s from being exposed as web services. The net result was that the application was tied to one particular database and this hampered database portability. Additionally, the challenge involved in working simultaneously with both Java and .NET based API’s and the studying the level of interoperability between these two technologies was a revelatory learning experience.

16. CONCLUSION

16.1 Conclusions Inferred

The aim of the current project was to develop business components in EJB and integrate it across platforms to a .NET system. This involved deploying and exposing the EJB’s as web services through AXIS. AXIS and the ASP .NET system had to work together in accessing third party components. This process required some workaround; hence AXIS and ASP .NET require further optimizations to work seamlessly with each other. Parsing of SOAP messages back and forth to native language calls implied a communication overhead. Hence cross-platform integration is not suited for web applications that require speedy communication with business components.

16.2 Java (Vs) .NET: A programmer’s perspective

Both Java and Microsoft .NET have pros and cons when viewed from a programmer’s perspective. .NET has a strong IDE support that allows commonly used components in a web application to be dragged and dropped onto the page. This ease-of-use alleviates the programmer for writing code for commonly used components, while in the case of Java, the IDE’s commonly used in an academic environment do not provide the same level of ease-of-use. A number of commonly used components have to be coded by the programmer. To obtain a comparative ease-of-use functionality a programmer has to go in for a commercial and costly IDE. .NET is highly optimized for Rapid Application Development (RAD) and enterprise web application can be up and running in no time. This is possible as the framework is optimized and deals with a number of system files and dll files. Debugging then becomes difficult as things work under the hood and are non-transparent. Contrast this with Java, being an open-source language where the programmer gets a clear picture of how things work under the hood and in the process debugging applications becomes easier if not straightforward.

17. LESSONS LEARNED

The aim of the current project was to evolve a cross–platform component based ecommerce framework that involved developing business components in EJB and integrate them into a .NET system. The medium of integration was through web services. I got an idea about the concepts involved in service oriented architecture and an understanding of the role of web services in cross-platform integration. I learned about the API’s available in .NET and Java for exposing business components as web services. I understood the complexities involved in web services testing as also the role of JBoss and AXIS and how they integrate together in exposing business components as web services.

18. FUTURE WORK

The current project has just scratched the surface in cross-platform integration through web services. There is scope for extending the project further to go deeply into issues involved in cross-platform integration. These include

• Improving security by using extending SOAP headers to carry authentication information

• Including and exposing package tracking facilities as web services to obtain real-time data on orders.

• Using the API’s provided by .NET and J2EE for working with XML for analyzing inventories, and generating order invoices

Organizations are also involved in extending JSR to bring container managed beans under the purview of web services that would ensure freedom from writing database access code and provide database portability.

19. REFERENCES

[1] Chad Vawter and Ed Roman. J2EE vs. : A comparison of building XML-based web services. June 2001

[2] David Chappell and Tyler Jewel. Java Web Services. O’Reilly Publications, March 2002

[3] David Muldrow. Understanding Web Service Invocations. April 2002

[4] Vivek Chopra, Gary Damschen, and Chris Dix. Professional XML Web Services. Wrox Press, September 2001

[5] Microsoft Developer Network ()

[6] Axis Project Pages ()

[7] Developing Web Services with Axis

()

[8] Interoperable Web Services ()

[9] IBM Journal of Research and Development ()

[10] JBoss Official Web Site ()

[11] Axis Project Pages / DotNetInterop

()

-----------------------

DATABASE

VENDOR

(.NET)

J2EE

Web Service

.NET

Web

Service

proxy

VENDOR BUISNESS LOGIC

BUYER

EJB

DATABASE

BASE

EJB

J2EE Web Service

SOAP

PROXY

VENDOR

(.NET)

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download