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
1
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
2
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 XMLbased 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.
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
3
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
Microsoft.NET8 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. Microsoft.NET 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 Microsoft.NET is shown in Fig 2
4
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
(ADO.NET) 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 (ASP.NET) which render user interfaces in HTML, XHTML, or WML. Heavyweight user
interfaces are built using Windows Forms.
5
The .NET Framework
Microsoft.NET 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 VB.NET, 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.
6
Understanding J2EE and .NET by analogy
To help you understand both models, we offer analogies between J2EE and .NET technologies in
Table 1 [1]
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
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
7
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:
8

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
9
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
10
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
11
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.
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).
12
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
13
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
14
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
Fig 4: Typical web service invocation scenario [3]
15
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.
16
6. SOAP: THE SOUL OF WEB SERVICES
6.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
17
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
soap:encodingStyle="http://schemas.xmlsoap.org/soap
/encoding/">
<soap:Body>
<w:Greeting xmlns:w="http://www.wrox.com/helloworld/">
<w:message>Hello world!</w:message>
</w:Greeting>
</soap:Body>
</soap:Envelope>
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:
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.
18
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:
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:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/
encoding/">
<soap:Header>
<h:from
xmlns:h="http://www.wrox.com/Header">SoapGuy@wrox.com</h:from>
</soap:Header>
<soap:Body>
<w:GetSecretIdentity xmlns:w="http://www.wrox.com/heroes/">
<w:codename>XSLT-Man</w:codename>
</w:GetSecretIdentity>
</soap:Body>
</soap:Envelope>
.
19
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
http://schemas.xmlsoap.org/soap/encoding/, 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,
20

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
21
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.
22
Fig 7: System Overview
VENDOR
(.NET)
.NET
Web
Service
proxy
SOAP/HTTP
J2EE
Web
Service
DATABASE
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.
23
9.2 System Architecture
The figure below represents the detailed system architecture.
IIS SERVER
JBOSS APPLICATION SERVER
VENDOR
LOGIC
BUYER
SOAP/HTTP
VENDOR
(.NET)
J2EE
Web
Service
SOAP
PROXY
BUISNESS
EJB
DATABASE
EJB
Serializes the native .NET method
calls to XML
BASE
De-serializes the SOAP Messages to
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 ASP.NET 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
24
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
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.
25
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.
26

Buyer Module
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
27
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
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.
28
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.
29
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.
Fig 14: Sequence Diagram for Shipping Cost Calculation
30
Fig 15: Sequence Diagram for Credit Card Validation
Fig 16: Sequence Diagram for Tax Calculation
31
9.6 Database Schema
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
32

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.
10.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
Fig 18: Home Page
33
Fig 19: List of books available
Fig 20: Shopping Cart contents
34
Fig 21: Communicating between a .NET system and a web service
Fig 22: Displaying order details
35
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
36
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.
37
Avg Response Time (ms)
.
140
120
100
80
Java Web Service
.NET Web Service
60
40
20
0
0
20
40
60
80
No of Iterations
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.
.
140
120
Avg Response Time (ms)

100
80
Java Web Service
.NET Web Service
60
40
20
0
0
20
40
60
No of Iterations
Fig 25: No of Iterations (Vs) Response Time (40 threads)
38
80
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.
45
40
Avg Response Time (ms)

35
30
25
Java Web Service
20
.NET Web Service
15
10
5
0
0
10
20
30
40
No Of Iterations
Fig 26: No of Iterations (Vs) Response Time (20 threads)
39
50
.
No of Iterations (Vs) Response Time (40 threads)
30
Avg Response Time (ms)

25
20
Java Web Service
15
.NET Web Service
10
5
0
0
10
20
30
40
50
No of Iterations
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
40
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
41
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 easeof-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
42

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. Microsoft.NET: A comparison of building XMLbased 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
http://www.research.ibm.com/journal
[4] Vivek Chopra, Gary Damschen, and Chris Dix. Professional XML Web Services. Wrox Press,
September 2001
[5] Microsoft Developer Network (http://www.msdn.com)
[6] Axis Project Pages (http://ws.apache.org/axis)
[7] Developing Web Services with Axis
(http://www.onjava.com/pub/a/onjava/2002/06/05/axis.html)
[8] Interoperable Web Services (http://www.thirdm.com/articles/alesso.htm)
[9] IBM Journal of Research and Development (http://www.research.ibm.com/journal)
[10] JBoss Official Web Site (http://www.jboss.org/index.html?module=bb)
[11] Axis Project Pages / DotNetInterop
(http://nagoya.apache.org/wiki/apachewiki.cgi?AxisProjectPages/DotNetInterop)
43