Download Comparisons of Middleware Technologies in JAVA World

Project_Report@Computing_School_of_LEEDS_Univ.
Comparisons of Middleware
Technologies in JAVA World
Author: HaiChen
LI
MSC. Information Systems
(2002/2003)
The candidate confirms that the work submitted is his own and the appropriate credit has been
given where references has been made to the work of others.
Signature of student:
.
I
Summary
This project aims to compare and contrast the middleware technology in JAVA world.
It consists of two objectives: 1) Compare and contrast the development of distributed
systems that use Web Services with systems that use lower-level middleware
technology based around the concept of remote method invocation (These are the
minimum requirements). 2) Compare how Web Services implemented within
Microsoft's .NET framework are different from implementations in the Java world.
(This is an optional in original mind)
To meet the objectives, a project plan was made in the early stage and the work has
been divided into four parts. Four parts work had being done step by step. All contents
were put into this report. As a result of that, most of the objectives are met.
In literature research part, some definitions, such as the distributed systems,
middleware technology were studied in detail. Especially, the concepts and rationale
of RMI representing the old middleware technology and Web Services representing
the new middleware technology were illustrated here.
In theory part, the rationale and the basic technology, protocols of RMI and Web
Services were studied and compared here. Consequently, the comprehensive
comparison of middleware technology listed in the last part.
In experiment part, the performance of RMI and Web Services was tested. J2SDK
1.4.2 and JWSDP1.2 were selected here to support the whole experiment. Firstly, the
rationale of RMI program model and JAX-RPC program model is studied. Secondly,
two testing scenario for the performance issue is designed carefully. The physical
configuration is also listed in this part. The result of the entire experiment is showed
in several statistic tables. Finally, the usability of the different methods is stated here.
In fact, finishing last three parts means the minimum requirements achieved.
In the platforms comparison part (it is an optional work), the main task focuses on
comparing the overall J2EE vision as defined by Sun (the owner of the specification)
to the overall .NET platform vision as defined by Microsoft. After I studied the
architectures and framework, the results are listed in several tables. Meanwhile,
technology equivalences and technology differences are also stated here.
Finally, I tried to make a serious conclusion. The result is simple. RMI is still applied
due to its unique features. Web Services, however, has earned a prosperous future for
its characteristics. J2EE and .NET have their own preferences in some extents.
I
Acknowledge
In this project, I would like to acknowledge the following people for their kind and
their persistent supporting.
Nick Efford
My supervisor. Not only his professional steering, he always refresh my mind from
the begin to the end, but also his science attitude, “make the things simple”
encouraged me in this half year and in the future life.
Peter Dew
My assessor, thanks for his time and his VWE lectures.
Ann Robert
My project officer, who considered more human factor like a wise lecture manager.
My Friends
Whoever love or hate.
II
Table of Contents
SUMMARY ................................................................................................................... I
ACKNOWLEDGE.......................................................................................................II
CHAPTER ONE: INTRODUCTION .........................................................................1
1.1 MOTIVATION .....................................................................................................1
1.2 OBJECTIVES .......................................................................................................1
1.3 APPROACHES AND STRUCTURE ..........................................................................2
CHAPTER TWO: LITERATURE REVIEW............................................................3
2.1 DISTRIBUTED SYSTEMS .....................................................................................3
2.2 MIDDLEWARE SOFTWARE..................................................................................3
2.3 JAVA REMOTE METHOD INVOCATION (RMI) ....................................................5
2.4 WEB SERVICES ..................................................................................................6
The History of Web Services ...............................................................................7
The Rationale of Web Services............................................................................7
The Architecture of web services ........................................................................8
CHAPTER THREE: COMPARISON OF RMI AND WEB SERVICE IN
THEORY WAY ..........................................................................................................10
3.1 INTRODUCTION ................................................................................................10
3.2 RATIONALE COMPARISONS ..............................................................................10
3.3 PROTOCOL COMPARISONS ...............................................................................11
3.4 COMPREHENSIVE COMPARISON OF MIDDLEWARE TECHNOLOGIES ..................13
CHAPTER FOUR: COMPARISON OF RMI AND WEB SERVICES IN
EXPERIMENT WORLD...........................................................................................14
4.1. INTRODUCTION ...............................................................................................14
4.2 THE RATIONALE OF DEVELOPING METHOD .......................................................14
RMI Rationale ...................................................................................................14
JAX-RPC Web Services Rationale ....................................................................14
4.3 EXPERIMENTAL DESIGN...................................................................................15
Test Scenario design .........................................................................................15
Test Method and Strategy..................................................................................16
Machine Configuration .....................................................................................17
4.4 EXPERIMENT RESULTS .....................................................................................18
4.5 DISCUSSIONS AND CONCLUSION ......................................................................21
4.6 USABILITY .......................................................................................................22
CHAPTER FIVE: COMPARISON OF THE WEB SERVICES PLATFORMS.23
5.1 INTRODUCTION ................................................................................................23
5.2 J2EE................................................................................................................24
5.3 .NET................................................................................................................25
5.4 COMPARE J2EE AND .NET..............................................................................27
Technology equivalences ..................................................................................27
Technology Difference ......................................................................................28
5.5 CONCLUSIONS..................................................................................................30
a
CHAPTER SIX: EVALUATION AND CONCLUSION ........................................31
6.1 INTRODUCTION ................................................................................................31
6.2 EVALUATION ...................................................................................................31
6.3 CONCLUSION ...................................................................................................32
6.3.1 RMI...........................................................................................................32
6.3.2 The disadvantage of web services ............................................................32
6.3.3 The advantage of web services.................................................................33
6.4 SUMMARY AND SUGGESTION ...........................................................................35
REFERENCES: ..........................................................................................................35
APPENDIX A: REFLECTION ON PROJECT EXPERIENCE ...........................39
APPENDIX B: COPY OF THE OBJECTIVES AND DELIVERABLES FORM41
APPENDIX C: COPY OF THE INTERIM REPORT............................................42
1 COPY OF THE MARKING SCHEME ........................................................................42
2 COPY OF THE HEADER SHEET FOR THE MARKED INTERIM REPORT, .....................42
3 COPY OF THE COMMENTS FROM THE ASSESSOR...................................................42
APPENDIX D THE PROJECT PLAN .....................................................................43
APPENDIX E THE LINK FOR PROJECT LOG...................................................45
b
Chapter One: Introduction
1.1 Motivation
The revolution and evolution of computer technology has improved dramatically in
the past two decades. In the view of hardware the speed of CPU became faster
accompanying its performance. In the view of software the applications spread its
scale more widely. The emergence of Internet and WWW expanded the scope of
computer applications into distributed systems. All of the above brings the
development of software into a new world, the heterogeneous environment. In this
distributed heterogeneous environment, there exist not only the hardware system
platforms, such as the PC, workstation and mini computer, but also various software
systems, such as different operating systems, databases, languages. Furthermore,
various user interfaces with different styles are on the show. Those software and
hardware system platforms might connect to each other with different net protocols
and network infrastructures. It is a very tough issue to integrate those systems to
develop new applications or to share information and software resource in such
heterogeneous environment. How to support enterprise application integration and
Web applications challenges the middleware design principles.
A robust distributed computing framework will bring enormous advantage to the
development of distributed application. Looking into the distributed system
technology, we know the middleware layer aims to cover the complexity of the
heterogeneous environment. It masks the difference of computer architectures,
operating systems, programming languages, and networking technologies to facilitate
application programming and management.
Middleware research and development has reached the end of its first major phase.
New trends are arising. They are so fundamentally different with the old middleware
technology and will lead to new-generation middleware systems.
Those new technologies also pose several questions. What is the most appropriate
programming model for diverse application scenarios? What is the new feature of the
new middleware platforms? Which model or platform is more convenient and
effective for the developers? These issues not only frame the agenda for future
middleware research development but also generate open research problems requiring
building applications atop new middleware prototypes. [1]
1.2 Objectives
The project will compare and contrast the development of distributed systems that
use Web Services with systems that use lower-level middleware technology based
around the concept of remote method invocation (RMI).
The project also compares how Web Services implemented within
Microsoft's .NET framework and those within the implementation in the Java
1
world.
1.3 Approaches and Structure
This paper is divided into five parts. The first part is the background research,
including the general concepts of middleware and the common foundations of
distributed systems. There are two representative development methods: one is RMI.
The other is an emerging method, Web Services. Not only the concepts but also the
theories are discussed in this part. Secondly, the author mainly compares the RMI
method and Web Service method in the theory way. Following the historic reasons,
the article compares the rationale of two middleware technologies mentioned above.
The third part of my project is the comparison in experiment. One experiment is
designed and implemented in different ways (RMI and Web Services) here. In the
following part, to achieve the optional task, two different platforms in the real world
about how to develop the middleware (especially the Web Services) are compared
here, which are J2EE and .NET. Finally, a dedicate conclusion is made in the light of
the theory explored and the experiment result.
2
Chapter Two: Literature Review
In this part, the general concepts and theory of middleware for the distributed systems
are explored. In further, the history and the major opinions about how to develop the
middleware are discussed in the camp of RMI and the castle of Web Service.
2.1 Distributed Systems
Various definitions of distributed systems have been given in the literature, none of
them is satisfactory and none of them in agreement with any of the others. A
distributed system is one in which components located at the networked computers
communicate and coordinate their actors only by message passing. [6] Briefly a
distributed system enables resources to be distributed around the network such as
Software applications, and Clients and servers. For our purposes it is sufficient to give
a loose characterization:
“A distributed system is a collection of independent computers that appears to its
users as a single coherent system.” [5]
This definition has two aspects. The first one is “distributed” feature. It deals with
hardware: the machines are autonomous. The second one is “systems” feature. It deals
with software: the users think they are dealing with a single system. Both are essential.
The distributed object technology emerged with the further development of
object-oriented technology. Distributed object technology establishs application
system frame and object component under the distributed isomerism environment.
The developer can packing the software function to easier management and the use
object under the support of application system frame. These objects can carry on the
mutually operation cross different software and hardware platforms. It can be said that
distributed object technology is inceasingly consummated with the development of
network and object-oriented technology.
2.2 Middleware Software
Distributed object technology emerged accompanying the network development.
Since most of the original computer systems are personal computer system,
multi-users access each other through the online terminal without the concept of
Network. After the emergence of network, the service pattern of Client/Server was
born. Multi-users can share database-server and print-server etc. Further more,
following the network development, a lot of software need work in the heterogeneous
environments that consist of different network products and hardware products.
Meanwhile, the applied scope used to focus on local network now expands to WAN.
In this case, the limit of Client/Server pattern was exposed and the middleware
generated. [25]
Middleware is the common service between the operating system and application
software. Its main function is to shield the difference of network hardware platform
and heterogeneous of operating system and network protocol so that the application
software can quite smoothly run in the different platform. In addition, middleware
3
plays the major role on some aspects such as the load balance, connection
management and dispatched. It enables the performance of the the enterprise level
applications to obtain the large promotion and meets the need of essential transaction.
However, in this stage, the relationship between client and server is asymmetric
because client requests service and server provides service.
According to Figure 2-1, to support heterogeneous computers and networks while
offering a single system view, distributed systems are often organized by means of
middleware that is logically placed between a higher-level layer consisting of users
and applications and a layer underneath consisting of operating systems. [5] Applies
to the a software layer that provides a programming interface abstraction as well as
masking the heterogeneity of the underlying networks, operating systems and
programming languages. Some middleware is language dependent (e.g. Java) and
others like CORBA can handle modules written in a variety of computer languages.
Application
Presentation
Session
Transport
Network
Data link
Physical
Figure 2-1: The Logical View of Middleware Technology in the OSI Model
The Figure 2-2 shows a typical three tier middleware architecture: Client, Work
Group and Servers. By an enterprise system we mean a system that allows system
resources to be handled transparently across the enterprise networks (today often
using the Web). The middleware layer performs the function of separating out the
application service from the core system services (e.g. file servers, access to enterprise
data resources etc. [7] The middleware layer can be broken down into two further
layers: one is the Request-rely protocol. HTTP is an example. Another is Marshalling
& External data representation. It enabled serialization of the data to transmit across
the network.
Clients
Workgroup
Servers
Mainframe
Message Passing and Remote Invocation
to enterprise-wide resources
Security
Directory
of Services
(e.g. files)
Figure 2-2: The Physical View of Middleware Technology [cited from Peter Dew’s course slide]
The software model for middleware is shown in Figure 2-3. The middleware is
4
implemented on what is called the Platform Layer. This is the lowest level hardware
and software layer. It provides servicing to the layers above. The key distinguishing
feature is that the code is implemented separately for each processor. Bringing the
system’s programming interface up to the level that facilitates communication and
coordination between processes.
!
"
#
$
%
&
'
(
"
'
%
Figure 2-3: The Middleware Technology Model
[cited from Peter Dew’s course slide]
Remote Process Call (RPC) and group communication were the early models. Today,
this is being replaced by distributed object. The standards for Distributed objects are
managed by the Object Management Group (OMG), from which the Common Object
Request Broker (CORBA) was defined. In 1991, the promulgated of CORBA 1.0
standards opened the distributed object computation prologue. CORBA technology
appears earliest. Its standard was done perfectly at that time. [66] Another technology
is the series of COM of Microsoft. Distributed Component Object Model (DCOM)
was first made available in 1995 with the initial release of Windows NT 4. [60] From
the initial COM to current DCOM, it has formed a set of distributed objects
computing platforms of Microsoft. The third technology is Sun Java Remote Object
Innovation (RMI). However, Java platform of Sun only provides remote method
invocation when it was released at its beginning. And it certainly cannot be called the
distributed object computing. It only belongs to one kind of network computation.
JavaBean, the following release, is insufficient to confront above two genres. The
current edition named J2EE releases EJB, which also has component standard, except
language itself, and the framework of coordination communication between the
components. Those depend on Java’s homogeneous programming language
environment have received widespread attention. Thus, there are three genres at
present.
In conclusion, the developing methods of middleware mainly have several opinions.
In past time, the CORBA, DCOM and RMI are the key ideas. Nowadays, most
developer focuses on the Web Services. In this report, RMI representing the past and
Web services standing for the new trend are chose here to explain the concept and
history. The assessments are written separately.
2.3 Java Remote Method Invocation (RMI)
In Java view, RMI Architecture and Functional Specification states “Remote method
invocation (RMI) is the action of invoking a method of a remote interface on a remote
object. Most importantly, a method invocation on a remote object has the same syntax
5
as a method invocation on a local object”. [37]
RMI uses object serialization to marshal and unmarshal parameters and does not
truncate types, supporting true object-oriented polymorphism. [2] A JAVA based
program can make a call on a remote object once it obtains a reference to the remote
object, either by looking up the remote object in the bootstrap naming service
provided by RMI or by receiving the reference as an argument or a return value. A
client can call a remote object in a server, and that server can also be a client of other
remote objects.
RMI is very similar to an RPC when it comes to issues such as marshaling and
parameter passing. An essential difference between an RMI and an RPC is that RMI
generally support system-wide object. In addition, it is not necessary to have only
general-purpose client-side and server-side stubs available. Instead, we can more
easily accommodate object-specific stubs, such as Dynamic Invocation Interface and
Dynamic Proxy. [8]
RMI enables the programmer to create distributed Java technology-based to Java
technology-based applications, in which the methods of remote Java objects can be
invoked from other Java virtual machines, possibly on different hosts. RMI embeds
the distributed object model into Java language directly so that the Java programmer
may naturally compile the distributed procedure and need not to leave Java
enviroment or relate to CORBA IDL and the type transformation from Java to
CORBA. However, RMI does not observe the CORBA standard. It basically is the
techology from Java to Java and uses Java to compile both client procedure and
serve procedure. It is difficult for RMI to realize the mutually operation on other
language compilations objects.
2.4 Web Services
What is the definition of web service? There are many answers. Here we choose the
definition from W3C organization.
“A Web service is a software system identified by a URI [RFC 2396], whose public
interfaces and bindings are defined and described using XML. Its definition can be
discovered by other software systems. These systems may then interact with the Web
service in a manner prescribed by its definition, using XML based messages conveyed
by Internet protocols.”[30],[31],[32]
Why exists the Web Services? There are serveral histric reasons. One is the need of
data exchange. In early time documents transformation between enterprises was
achieved by EDI (Electronic Data Interchange). [67] However, most of EDI were
expensive and exclusive and used special protocols and documents specification, so
the maintenance cost was high and the expansion was not easy as well. Following the
popular of Internet, the protocol and specification, framework with high open-feature
became popular. Such as, TCP/IP, HTML, XML etc. Those rose the tide of
e-commence, such as the B2C (business to Client) and B2B (Businese to Businese). In
B2B, eMarketplace pattern realized, which provide a transaction place (a web site) by
the third party for businese entreprises. The existing issue was that the data inputing
was manual. As we known, the speed is the key point to be a core competition factor
6
in a enterprise. If the manual inputing method could be replaced by automate
exchange between the computer system, it can improve the entreprise competition and
reaction speed. Consequentlly, the web services was focused on since it integrated
every open standards. From this view, the Web Services has one feature that it
changes the old interaction way between user and application into new interaction
way between applications. [3]
Another reason for Web Services is the need of application interaction. The advantage
of web technologies, such as universal client side and easy maintenance, bring the
traditional application into the Browser-Server structure application. However, it also
exposes some issues accompanying its development. The web pages are designed for
human being not for applications. So, most of the message which are transferred
through the Internet have various styles reflecting the visual effect, such as picture,
diagram slice, form of written information, the plain text composed of type the style
etc. The essential high value message is buried deeply into the representative message.
It is difficult to be discovered and used by other applications. The most important
point is that the communication standard and interaction services are limited. As well
known, human’s eyes and mind are fast enough to locate the information he want in a
complicate web page, no matter what change happen in those web pages. The
applications, however, are so hard to fulfil the same task. That is the reason why we
need the web services for special application.
The History of Web Services
When the demand of communication between applications swells, the need of united
standards and principles increases too. HP Company, as one of the pioneers, is the
first one who brings forward the idea of Web services technology. In the spring of
1995, HP labs began working on e-Speak, one of the first products focused on Web
services. E-Speak enables service-to-service interaction by allowing the registration,
discovery and interaction of dynamic Web services. HP stated that it should be the
next generation Internet standard of information interaction. [29] Following,
Microsoft Company was aware of the beautiful vision and published the
strategic .NET. Soon after that, IBM released Web Services Toolkit (WSTK) and
Web Services Development Environment (WSDE) to declare its full supporting of
Web Services. Meanwhile, Oracle also developed own Dynamic Services and
integrated with Oracle 8i Release 2. Sooner, W3C established every standards and
principles of Web Services. Meanwhile, the SUN released its own Web Services
framework and integrated its standards of Web Services into J2EE environment. In
conclusion, above activities made Web Services abroad basement and platforms.
The Rationale of Web Services
Web services provide a series of standards and protocols to guarantee the dynamic
connection between applications. The fundamental protocols consist of SOAP, WSDL,
and UDDI.
SOAP (Simple Object Access Protocol) is a lightweight protocol for exchange of
information in a decentralized, distributed environment. It is a minimal set of
conventions for remote invoking using XML [68] over HTTP. [59] It is an XML
based protocol that consists of three parts: an envelope that defines a framework for
7
describing what is in a message and how to process it, a set of encoding rules for
expressing instances of application-defined data types, and a convention for
representing remote procedure calls and responses. SOAP can potentially be used in
combination with a variety of other protocols. [50] On May 2000, SOAP 1.1 was
submitted to W3C. [57]
WSDL (Web Services Description Language) is an XML format for describing
network services as a set of endpoints operating on messages containing either
document-oriented or procedure-oriented information. The operations and messages
are described abstractly, and then bound to a concrete network protocol and message
format to define an endpoint. Related concrete endpoints are combined into abstract
endpoints (services). WSDL is extensible to allow description of endpoints and their
messages regardless of what message formats or network protocols are used to
communicate. [51] On September 2000, WSDL 1.0 was published. On March 2001:
WSDL 1.1 was submitted to W3C [58]
UDDI is the abbreviation of Universal Description, Discovery, and Integration. It is a
specification for distributed Web-based information registries of Web services. The
service discovers protocol for Web Services through which companies can find one
another to conduct business. This standard was unveiled on September 2000 by Ariba,
IBM, Microsoft, and 33 other companies. [52] UDDI was first developed by
UDDI.org and then transferred to OASIS. UDDI.org was comprised of more than 300
business and technology leaders working together to enable companies and
applications to quickly, easily, and dynamically find, and use Web Services. [33] [53]
Table 2-1: The History of UDDI Specification [54]
VERSION
DATE
KEY OBJECTIVE
1.0
Sep. 2000
Create foundation for Registry of Internet-based
business services.
2.0
June 2001
Align specification with emerging web services
architectures and provide more flexible taxonomy
3.0
July 2002
Support wide interaction of private and public
implementations
The Architecture of web services
The Web services architecture describes three roles: Service provider, Service
requester and Service broker. Web services components provide three basic
operations: Publish, Find, Bind. In order for some component to become a Web
service, it must be: 1) Created, and its interfaces and invocation methods must be
defined. 2) Published to some repository. 3) Easy to locate by potential users. 4)
Invoked and implemented by users. 5) Unpublished when it is no longer available.
Web service descriptions can be created and published by service providers who
create on-line resources for personal and business use. Web services can be
categorized and searched by specific broker services. Web services can be located and
invoked by requesters of the services. [4]
8
Discovery
Agencies
Service
Description
Find
Publish
Service
Service
Requestor
Service
Provider
Interact
Service
Description
.
Figure 2-4 Web services architecture roles [4]
The figure 2-4 above illustrates the basic Web services architecture. A service
provider create a service publish it to a discovery agencies. The service requestor find
this service in the angencies and interact with the provider to exchange messages. The
Web Serives happen.
In generally, Web Services are self-contained, modular applications that can be
described, published, located, and invoked over a network. It could be weather reports
or stock quotes, transaction Web services, supporting business-to-business (B2B) or
business-to-client (B2C) operations, could be airline reservations or purchase orders.
Web services reflect a new "service-oriented" approach to programming, based on the
idea of building applications by discovering and implementing network-available
services, or by invoking available applications to accomplish some task. This
"service-oriented" approach is independent of specific programming languages or
operating systems. Instead, Web services rely on pre-existing transport technologies
(such as HTTP) and standard data encoding techniques (such as XML) for their
implementation.
9
Chapter Three: Comparison of RMI and Web
Service in theory way
3.1 Introduction
In theory way, the rationale and the basic technology, protocols will be studied and
compared step by step. To discuss the reason why Web Services was generated atop
the old middleware technology is the main rationale comparisons in this part.
Consequently, the comprehensive comparison will be list on the last part.
3.2 Rationale Comparisons
Among the old middleware technology, most distributed application systems use the
RPC to access the remote services, Such as, DCOM of Microsoft, RMI of SUN,
CORBA of OMG, etc. The advantage of RPC-based distributed framework is that it
provides developer the familiar development method (function call) and location
transparency. The disadvantage is as follow:
Tightly-coupled. A special call method between the client side and server side
should be specified. Client side should know how to access the detail of those
services in server side. Such as the parameter and status. If the server side changes
a bit, the client side may not work well.
Only synchronous calls. When client side calls the process in server side, it must
wait and only wait until the process is end before next step. Though, there are
many skills to solve the problem, those will increase the complication of program.
Further more, the program is difficult to code.
When applications need to execute tasks asynchronously a so-called information
directed structure is derived, such as MSMQ of Microsoft, [69] MQSeries of IBM,
[70] etc. Different from the process of RPC transfer method, this structure utilizes
asynchronous information transmission system, and the client can continue to perform
other tasks as soon as the information is sent out. Its greatest advantage is that the
information is guaranteed that it will be sent to the destination without any certainty
of when it will arrive. However it has some disadvantages as follows:
It performs on a first-come-first-deal basis (array), unable to provide a specific
workflow execution sequence.
Programmers have to deal with the wrapping, encoding, and testifying information
package, which are not an easy job.
The solutions provided by different enterprises are incompatible.
No matter it is RPC or information directed structure, they have a common
disadvantage that is they will be bound to specific working environment or software,
and different products explore different transmission protocols or information formats,
which makes communication impossible between one another. What’s more, some
binary protocols, such as DCOM, RMI, and CORBA, will be blocked. Thus
information service cannot be directly saved or obtained from outside. Therefore,
10
network maintenance personnel have to dig a hole on the wall to permit them to get
through the firewall, such as tunnelling, which will definitely evoke network security
problems. It is also a drawback in the current distributed structure, a headache for
professionals.
To solve these problems, Web services emerged, as the times require. It acquires the
following characteristics:
Loosely-coupled distributed structure
Providing synchronous and asynchronous process transfer
Stateless
Neutral platform, irrelevant to practices (developing tools and programme
languages)
Easy to break through firewalls
However, it is not to say that Web Services can entirely substitute for traditional
distributed technologies. It only demonstrates that each has its own applicable
environment. To evaluate which technology should be exploited to develop
application programmes, it is not only to comprehend the advantages and
disadvantages of the technology itself, but also to understand the requirements of the
application programmes and the limitation of the environment, so as to not make it
happen that advanced technology produces useless software. [19]
3.3 Protocol Comparisons
The old distributed technologies can’t universally connect to each other since the
variety of Internet technologies. For example, DCOM needs each connect end is
underneath Windows. CORBA needs each connect end is ORB. RMI needs each
connect end is JAVA. Comparatively, SOAP is a platform independent since
Simple XML style.
Any technologies on Any platforms.
Open source code resource.
The underlying networking protocols on which middleware systems are built are IP,
UDP, and TCP. In this report, the middleware systems we focus on
RMI (Remote Method Invocation)
Web services (SOAP/WSDL/UDDI)
11
Table 3.1 The Comparison of RMI and Web Services [17][35]
RMI
Web Services
Data representation Java Marshalled Object
(what is moved)
SOAP
Transport (how it JRMP (Java remote various,
is moved)
method protocol)
HTTP
usually
Service description
Java interface
WSDL
Locating services
RMI Naming Service
UDDI
Lookup matching
Exact string match
String searches
Language bindings
Java only (JDK 1.1 on, Java, .NET, Perl
not Visual Java)
Language
paradigm
Method call
Remote reference
Proxy object
URL
Synchronicity *1
Synchronous
Synchronous
Procedure call
Garbage collection Yes
*2
No
*1 Some middleware systems support event mechanisms for asynchronous processing,
some only support synchronous processing
*2 Some systems will garbage-collect objects/services and clean up registries. Others
won't.
RMI is a way for programmer using the objects to communicate in JAVA language
environment. Those objects may distribute in distributed network environment. It is
code in Java, transfer by JRMP. In generally, it is synchrony and base on TCP/IP
protocol. Further more, it can invoke remote objects. But RMI is only for JAVA object
invocation. It provides a simply mechanism for java method which run in different
memory and intranet and Internet. [38] [39]
To skip the field of RMI, we can touch the web services, which are consist of XML,
SOAP, UDDI, and WSDL. XML and SOAP is system independent, and will be a
good quality and price rate in future since most develop manufacturer support them.
Not like RMI, SOAP is a synchronous and asynchronous web transaction XML
criterion. [18] In fact, it is an XML based protocol using RPC go through the firewall.
SOAP uses the return information that consists of HTTP request and response as the
method call mechanism. This allows the protocol go through the firewall. SOAP also
allows the XML based documents code their opera ability information detail. The
information of execute method are put into HTTP head and body, which will be
12
transferred in web.
3.4 Comprehensive Comparison of Middleware technologies
To overlook the whole picture of middleware technologies and understand the
difference, a comprehensive table is listed in table 3-2. The middleware technology of
COM/DCOM belongs to a framework, which is analogical to EJB and CORBA
construction models. However, CORBA itself has two meanings: it is both a standard
of a framework and a distributed application service standard, a frame. What can be
analogical is Web Service infrastructure or COM+ (the extension of DCOM + MTS).
As a communication protocol, SOAP functions similarly as RMI, ORPC, and IIOP,
which can be illustrated by the following table: [20]
Table 3-2: The Comprehensive Comparison of Middleware Technologies
Service
Component
Framework
Model
Communication Interface
Protocol
Service
Description Discover
CORBA
CORBA_coms IIOP
IDL
CORBA_based
J2EE
EJB
RMI
JAVA
JNDI
COM+
COM/DCOM
ORPC
MIDL
Registry
Web
Services
above
SOAP
WSDL
UDDI
13
Chapter Four: Comparison of RMI and Web
Services in Experiment World.
4.1. Introduction
There are many software vendors providing the Web services implement
methodology. The methodology includes the performance testing, security testing,
usability etc. In this experiment, we consider the first one and the last one. Regarding
the RMI as the representative of the past middleware technology, I choose the JAVA
Web services comparatively as the representative of Web services since RMI is
realized in JAVA world. It means that the JWSDP1.2 will be considered as the main
reference object. Also considering the experiment condition, I ran it in a local network
after downloaded the free package form SUN web site. In JAVA view, there are two
main APIs to develop Web services. One is Java API for XML-Based RPC
(JAX-RPC)[72] another is Java API for XML Message (JAXM) [73]. Here I select
the previous to compare the RMI program since the RMI is based on RPC too. [25]
In this part, after studying the rationale of RMI program model and JAX-RPC
program model firstly, I designed two testing scenarios for the performance issue.
Finally, the usability of the different methods is stated here.
4.2 The rationale of developing method
RMI Rationale
From figure 4-1, we know that the process of a RMI begin at a client program makes
method calls on the proxy object, RMI sends the request to the remote JVM, and
forwards it to the implementation. Any return values provided by the implementation
are sent back to the proxy and then to the client's program. [49]
RMI
System
Client Program
Server Program
Stubs & Skeletons
Stubs & Skeletons
Remote Reference Layer
Remote Reference Layer
Transport Layer
Figure 4-1 The Rationale of RMI at Runtime [48]
JAX-RPC Web Services Rationale
From the figure 4-2, we know the process detailed description of what happens at
14
runtime of a JAX-RPC web service after it’s been deployed. [44]
1.
To call a remote procedure, the client side program invokes a method on a stub, a
local object that represents the remote service.
1.2. The stub invokes routines in the JAX-RPC runtime system.
1.3. The runtime system converts the remote method call into a SOAP message and
then transmits the message as an HTTP request.
1.4. When the server receives the HTTP request, the JAX-RPC runtime system
extracts the SOAP message from the request and translates it into a method call.
1.5. The JAX-RPC runtime system invokes the method on the tie object.
1.6. The tie object invokes the method on the implementation of the Web Service.
1.7. The runtime system on the server converts the method's response into a SOAP
message and then transmits the message back to the client as an HTTP response.
1.8. On the client, the JAX-RPC runtime system extracts the SOAP message from the
HTTP response and then translates it into a method response for the client side
program. [71]
WSDL
Document
Import
Web Service
Client
Publish
Web Service Invocation
Service
Runtime System
Web Service
Endpoint
Service
Runtime System
SOAP
HTTP
Client Side
Server Side
Figure 4-2 JAX-RPC at Runtime. [62]
4.3 Experimental Design
The performance testing includes at least four aspects. They are the latency, the
capacity, CPU usage and the memory page file usage. [22][23] I select two main
indexes to compare the efficiency and effort of RMI and Web Services in Java world.
One is Latency and another is Scalability. According to [43], latency mean that “the
time that elapses between a stimulus and the response to it.” Scalability is “How well
a solution to some problem will work when the size of the problem increases”. In
addition, the memory consume rate also are considered here.
Test Scenario design
From the rationale of RMI and JAVA Web Services, we understand their performance
15
depends on a number of factors. In client side, the latency of looking up the remote
method in a specific RMI registry server or a Web Service in a Tomcat application
server is a main delay. It not only depends on the quality of network transport but also
on the status of the remote server. For example, if the RMI registry didn’t work well,
the client will spend much time to lookup the methods that are registered in server
side.
Except for that, the latency of methods call is also an important factor. When the
connection is build between the client side and the server side, how long the direct
method call is need become a key factor.
Further more, the amount of the memory consumption are believed a good index for
the performance. Here we mainly test how much the server will occupy each time.
How much the method call will occupy when it bind or deploy. How much the client
will consume. In addition, the CPU usage factor is a difficult measured index as well.
The tests method used in this comparison experiment are two common technology
scenarios. One is accessing the remote data. Another is the remote computing. To
make the test scenarios as real as possible, the whole test will implement 10 times for
general thinking. The method calls will implement 10000 times since the unit of run
time is based on millisecond.
The SayHello ()
The SayHello method accepts a request from client and returns a string. It stimulates
the general need of distributed system. This method will be realised both in RMI way
and JAVA Web Services way.
The Sum ()
The Sum method accepts a request from client and returns the result after computing
two parameters. This method represents the typical distributed computing technology
in the real world. This method will be realized both in RMI way and Web Services
way too.
Test Method and Strategy
In the tests, I choose the DOS interface instead web page as the presentation tier when
we calls the remote object containing the test code. We can get better accurate
performance data rather than behind a web server since we test the core techniques
directly. As I mentioned earlier, there are two mainly latency performance indexes
when the connection is setting up between the server side and the client side. They are
the connect latency of looking up or searching the server and the method call latency.
In the experiment, System.currentTimeMillis() function is used to record the
beginning time and the ending time when the two index scenarios happen. Some
example codes are listed as following.
16
Looking up and connect latency test method in the RMI program,
! "##"$
%& ' $"#
(
"
) *
+
!
) *,
Searching time and connect latency test method in the Web Services program.
-
(
./ !
/0 1
2
/0
/0
) *
+
!
) *,
When the remote methods RemoteObj.sayHello() and RemoteObj.sum() in RMI way,
the remote methods Hello.sayHello() and Hello.sum() in Web Services way, only the
function running time was recorded in the experiment. The process to test the latency
time of the method call is same as the above method. The details are omitted here.
Machine Configuration
The following tables provide a brief summary of the test bed configuration used to
perform the tests.
Table 4.1 Client Machine Configuration
Number of
clients
1
Machine/CPU
DELL
Latitude C40
#
of
CPUs
1
Memory
Disk
Software
256M
30G
Windows XP;
JWSDP1.2
J2SDK1.4.2
Table 4.2 Application Server Configuration
Number
of clients
1
Machine/CPU
# of CPUs
Memory
Disk
Software
TOSHIBA Satellite
2430-402, P4 2.53G
1
512M
40G
Windows XP;
JWSDP1.2
J2SDK1.4.2
Table4.3 Router configuration
Number of
clients
1
Machine/CPU
Binatone ADSL 2000 Ethernet
Router
& USB
17
# of
CPUs
1
Software
Build-in
The machine configuration chart of my experiment is showed below.
. Figure 4-3: The Experiment Configuration.
4.4 Experiment Results
Each experiment is implemented 10 times. Each method call is implemented 10000
times. The record includes the latency time and the memory consumption. The unit is
millisecond. The details are below.
Table 4-4: The Latency of Lookup or Search Services
It shows that RMI spend 25 times latency looking up the RMI registry server than a
JAVA Web Service searching the provider’s server. The latency of RMI looking up is
1.3976 milliseconds. The latency of JAVA Web Services searching server is 0.0547
milliseconds.
18
10 0 0 0 0
90000
80000
70000
60000
50000
40000
30000
20000
10 0 0 0
0
1
2
3
4
5
6
7
8
9
10
Avg.
Tmes
i
Table 4-5: The Latency of Get a String in RMI and Web Services
It shows the latency comparison that a JAVA Web Service take 3 times time as RMI
do to finish a simply call for getting a string from the server side. Every time, the
method call in RMI is 2.5615 milliseconds and that in Web Services is 8.4067
milliseconds.
90000
80000
70000
60000
50000
40000
30000
20000
10 0 0 0
0
1
2
3
4
5
6
7
8
9
10
Avg.
Tmes
i
Table 4-6: The Latency of Sum service in RMI and Web Services
It shows the latency comparison that a JAVA Web Service take 6 times time as RMI
do to finish a simply call for a computing service. In RMI, the latency is 2.0123
milliseconds. In Web Services, the latency is 8.0691 milliseconds.
Table 4-7: The Comparison of Get a String and Sum service in RMI
19
It announces that getting a string spends much time than getting a sum computing
service in RMI. The gap is about0.5492 milliseconds.
Table 4-8: The Comparison of Get a String and Sum service in Web Services
It announces that getting a string spends much time than get a sum computing service
in a Web Service. The gap is 0.3376 milliseconds. The gap of these two differences in
RMI is longer than in Web Services. It is about two times.
Table 4-9: The Consumption of A RMI
Table 4-10: The Consumption of A Web Service
20
The above two charts shows the general amount of resource consumption in a RMI
process and a JAVA Web Service process. The main memory occupations come from
the consumption of the application server, Tomcat.
4.5 Discussions and Conclusion
The statistic above data are listed below
RMI
Connection Latency
1.3976
SayHello() average Latency
2.5615
Sum() average Latency
2.0123
SayHello() Latency *
3.9591
Sum() Latency **
3.4099
Gap latency ***
0.5492
Memory Consumption
27M
Web Services
0.0547
8.4067
8.0691
8.4614
8.1238
0.3376
66M
1.3429
-5.8452
-6.0568
-4.5023
-4.7139
0.2116
-39M
/
* SayHello() Latency = (Connection Latency + SayHello() average Latency)
** Sum() Latency = (Connection Latency + Sum() average Latency)
*** Gap Latency = SayHello() average Latency – Sum()average Latency
Figure 4-1 The Latency statistics
It is obviously that the JAVA Web Services spend much more time than the RMI call
in connecting period according to the above testing result. It is three times to get a
string from the server and six times to get the computing result. However, during the
first stage, to set up the connection between the client side and server side, the latency
of RMI program is longer than JAVA Web Services.
The gap of Sayhello() latency and the gap of Sum() latency are the amount of a RMI
and a Web Service. They are nearly twice and not as large as the gap in the average
latency.
The gap latency is the gap of SayHello() method and Sum() method in RMI and in Web Service. It
look like not as big as the gap between RMI and Web Services.
21
It shows that the performance of a Web service is poor than a RMI directly call.
However, since the experiment comparison is between the RMI and JAX-RPC, the
conclusion is only a limited result. Further more, the above two technology are based
on RPC. It means that JAX-RPC is only one of two kinds of Web Services
implementation technologies in JAVA world. What I can conclude is only represented
the comparison of performance of RMI and JAX-RPC.
RMI
1 Directly Connect performance better than Web Services
2 Maturity than Web Services
Web Services
1 new technology
2 good future only since its rationale
4.6 Usability
Since I coded Web Services program using Java Web Services development package
1.2 and coded RMI program in a simply word processing software, I strongly believe
that the JAVA Web Services is better than RMI to understand. What I consider in code
is only the method since JAX-RPC shields most of the detail of SOAP. However, in
RMI part, I have to deal with many details of the bound protocol and the lookup
protocol. It is complicated for the programmer to understand and deal with. JAX-RPC
is based on a remote procedure call (RPC) mechanism. It is developer friendly. RMI
involves a lot of complicated infrastructure, but JAX-RPC hide the underlying
implementation details invisible to both the client and service developer. Because of
its ease of use, JAX-RPC is the main Web services API for both client and server
applications, which focuses on point-to-point SOAP messaging, the basic mechanism
that most clients of Web services use. Although it can provide asynchronous
messaging and can be extended to provide higher quality support, JAX-RPC
concentrates on being easy to use for the most common tasks. Thus, JAX-RPC is a
good choice for applications that wish to avoid the more complex aspects of SOAP
messaging and for those who will find communication using the RPC model is a good
fit. JAX-RPC goes beyond basic RPC. For one thing, it is supports SOAP message
handlers, which make it possible to send a wide variety of messages. And JAX-RPC
can be extended to do one-way messaging in addition to the request-response style of
messaging normally done with RPC. Another advanced feature is extensible type
mapping, which gives JAX-RPC still more flexibility in what can be sent. [24][26]
22
Chapter Five: Comparison of the Web Services
Platforms
5.1 Introduction
Nowadays, there are two technical visions for B2B collaboration. One of these is the
Microsoft vision and goes by the overall name of the .NET platform [74]. The other is
the Sun vision and goes by the overall name of Java 2 Enterprise Edition (J2EE) [75].
In this paper, I will compare the overall J2EE vision as defined by Sun (the owner of
the specification) to the overall .NET platform vision as defined by Microsoft.
Technically, to meet web services requirement, the platforms should have been built
according to a pattern of an n-tier architecture that consists of: a front-end tier:
firewall (FW), load balancer (LB), a web-server tier (WS), an application server (AS)
tier, and a backend tier for persistent data, or the database tier (DB).[41] The
architecture chart is as following.
Figure 5-1: N-Tier Architecture [42]
5.2 J2EE
J2EE is Sun's Java platform for multi-tier server-oriented enterprise applications. The
basis of J2EE is EJB. [45] J2EE is a set of coordinated specifications and practices
that together enable solutions for developing, deploying, and managing multi-tier
server-centric applications. Building on the Java 2 Platform, Standard Edition (J2SE),
J2EE adds the capabilities necessary to provide a complete, stable, secure, and fast
Java platform to the enterprise level. It provides value by significantly reducing the
cost and complexity of developing and deploying multi-tier solutions, resulting in
services that can be rapidly deployed and easily enhanced The primary technologies
in the J2EE platform are: JAX-RPC, JavaServer Pages (JSPs), Java Servlets,
Enterprise JavaBeans (EJBs), J2EE Connector Architecture, J2EE Management
Model, J2EE Deployment API, Java Management Extensions (JMX), J2EE
Authorization Contract for Containers, Java API for XML Registries (JAXR), Java
Message Service (JMS), Java Naming and Directory Interface (JNDI), Java
Transaction API (JTA), CORBA, and JDBC data access API. [46]
Figure 5-2 J2EE components model (cited from java.sun.com)
Web Services is an essential component in the J2EE platform. J2EE provides a
framework for developing and deploying web services on the Java platform. The
JAX-RPC enables Java technology developers to develop SOAP based interoperable
and portable web services. Developers use the standard JAX-RPC programming
model to develop SOAP based web service clients and endpoints. A web service
endpoint is described using a WSDL document. JAX-RPC enables JAX-RPC clients
to invoke web services developed across heterogeneous platforms. In a similar
manner, the heterogeneous clients can invoke the JAX-RPC endpoints. [47]
Below is the figure for the J2EE architecture, it show the data flow in a N-tire
environment.
24
Figure 5-3 J2EE Architecture revised from [42]
5.3 .NET
Microsoft® .NET is a set of Microsoft software technologies for connecting
information, people, systems, and devices. It enables a high level of software
integration through the use of Web services—small, discrete, building-block
applications that connect to each other as well as to other, larger applications over the
Internet. [10]
The coming figure is the data flow in a .NET architecture.
25
Figure 5-4 .NET Architecture revised from [42]
.NET is Microsoft’s platform for XML Web services, the next generation of software
that connects our world of information, devices and people in a unified, personalized
way. The .NET platform enables the creation and use of XML-based applications,
processes, and Web sites as services that share and combine information and
functionality with each other by design, on any platform or smart device, to provide
tailored solutions for organizations and individual people. [13]
C++
C#
JScript
Common Language Specification
ASP.NET
Windows Forms
ADO.NET and XML
Base Class Library
CLR
Windows
COM+ Services
…
Visual Studio.NET
VB
Figure 5-5 .NET Framework
As shown in Figure 5-5, the .NET Framework is basically just a single platform that
anybody can develop for, using a system similar to Java/JVM. Only unlike Java/JVM,
there's no language barrier with .NET: The languages available to the developer upon
installation of the SDK are Managed C++, C#, Visual Basic and JScript; even more
are on the way. [11] It is the foundation of the next generation of Windows-based
applications that are easier to build, deploy, and integrate with other networked
systems. [12] Programmer build distributed Web-based applications with .NET,
which help to address the challenges of application integration. For example, they
help you to take different applications running on different operating systems built
26
with different object models using different programming languages and turn them
into easy-to-use Web applications. Like components, Web services represent
black-box functionality that can be reused without worrying about how the service is
implemented. You can assemble applications using a combination of remote services,
local services, and custom code. [15]
5.4 Compare J2EE and .NET
Figure 5-6 show us the evolution of middleware technologies, we know that .NET is
later than J2EE.
Figure 5-6 Ths History of Middleware Technolgies
Technology equivalences
To compare the framework of above two platforms, a technology equivalence table is
list as following.
Technology
.NET
J2EE
Distribution protocol
DCOM, SOAP
RMI/IIOP
Firewall
ISA*
not specified
HTML page caching
ISA*, ASP.NET
not specified
Language
Any of 20+
Java
OS platform
Windows
Multiple
GUI
WinForms/AWT#on J
Swing/AWT
Support technologies
27
Presentation
technologies
tier
Infrastructure
IIS
not specified
Programming model
ASP.NET
Servlets, JSP
High availability
NLBS*, ACS*, other
not specified
Load balancing
NLBS*, ACS*, other
not specified
Management
ACS*
not specified
Infrastructure
COM+
EJB
Programming tool
Visual Studio.NET
not specified
High availability
ACS*
not specified
Load balancing
ACS*
not specified
Security API
COM+ Security Call JAAS
Context
Message Queue API
MSMQ
JMS 1.0
Asynchronous
components
Queued (COM+)
Message driven beans (EJB
2.0)
Middle tier technologies
Naming and Directory ADSI
Service
JNDI
Data tier technologies
Distributed transaction
MS-DTC
JTS
Relational DB API
ADO.NET
JDBC 2.0
Hierarchical DB API
ADO.NET
-
Database storage
SQLServer**
-
Mainframe
connectivity
DB HIS*
Java Connectors
Table 5-1 The Technology Equivalences [42][40][64]
* Optional add-ons services for the .NET platform.
** SQL Server is the official .NET platform database technology, but any ADO.NET
compliant database, which includes most major databases, can be used.
Technology Difference
As shown in table 5-1, .NET and J2EE are combination of a set of related
technologies. Both platforms are designed for similar goals. The difference, however,
28
will compare as following.
Developing Language
C# of .NET and Java of J2EE derived from C/C++. Both have a plenty of common
features. Such as the automate memory management, Hierhcy Naming Space. C#
learn some component concepts from JavaBeans. (such as property/attribute and
event). However, it creates some new features (like metadata tag) and utilise different
grammar. When Java run in any OS platform with a Java VM, C# only run in the
windows environment. When C# run in IL system, compile in just-in-time, Java
implement same tasks in JVM. ASP+ supports Visual Basic, C# and other languages
to code and compile into IL, not same as the asp. JSP supports Java language to code
and compile into bytecode.
Run environment
In .NET run environment, IL, different program languages can use the same
components. But in J2EE, Java bytecode runs in compability virtual machine and
CORBA permit the objects with ORB in different languages and different platforms
communicate each other. Though, the extent of couple is not tight.
IDE
There are many similar web components in the standard Java platform to support Java
Swing. In other Java IDE, other vendors also support same components. In MS visual
Studio IDE, RAD tools, such as Win Form and Web Form are provided. Up to now,
no other vendors announce their support stage.
Protocol
In .NET, ADO+ support SOAP, the protocol about HTTP using XML to exchange data
in the remote objects. In J2EE, the protocol of EJB and JDBC depends on the
programmer. They can use HTTP, RMI/JRMP, and IIOP.
Comprehensive Comparison
The above is the technical details comparisons. The below is the comprehensive
comparisons.
.
J2EE
.NET
Support current distributed technologies.
CORBA
Y
N
RMI/IIOP
Y
N
COM+
N
Y
Support the Web services
XML-RPC
Y
N
SOAP
Y
Y
The current developing tools
JBuilder (Borland)
Visual Stdio.NET
Forte for Java (Sun)
WebLogic Workshop (BEA)
JDeveloper (Oracle)
VisualAge for Java (IBM)
Visual Café (WebGain)
29
Type
of Standard
Technology
30+
Vendors
Product
Microsoft
5.5 Conclusions
We have two competing visions for middleware developing architectures. Both J2EE
and .NET is the e-Commerce solution schema. They have similar architecture and
correspond technology. The main differences are the developing efficiency and effort,
the cost and the robust. Microsoft's .NET platform vision is a group of products rather
than specifications. The major disadvantage of this approach is that every application
only be run on .NET platforms. The advantages of the .NET platform include 1) the
cost of developing applications and running applications is much lower. 2) The ability
to scale up is much greater, with the proved ability to support at least ten times the
number of clients any J2EE platform has shown itself able to support. 3)
Interoperability is much stronger, with industry standard e-Collaboration built into the
platform. Sun's J2EE vision is based on a big specification. It is controlled by the Sun
Company, but implement by many vendors. One of J2EE's advantages is that the
applications all based on a single language, JAVA. Another is that most of the J2EE
vendors do offer operating system portability. It means that “Write once, Run
anywhere”. [64]
30
Chapter Six: Evaluation and Conclusion
6.1 Introduction
In this part, a general evaluation of the experiment will be given here. The conclusion
not only comes from the theory and the experiment but also comes from the
comparison of platforms.
6.2 Evaluation
To solve the original problems, the comparisons above are implemented and working
out a result. Definitely, there are also many other different solutions. However, all of
them can be cataloged into theory, experiment and tool item. The main difference
between this project and the three catalogues is the focus. For example, in experiment
part, there exists performance test, function test, security test and usability test etc.
Even only in the performance test, it also includes the efficiency, scalability, fault
tolerance, latency, CPU and Memory consumption etc. In this report, the testing point
mainly focuses on the performance issue of two kinds of middleware technologies in
Java world. The statistics of latency and the memory consume of RMI and Web
services are showed in some way.
In theory part, two representative middleware technologies in JAVA world are
discussed. However, the middleware technologies include not only the RMI and Web
Services but also the CORBA and COM+ etc. Although the paper selects the previous
two technologies to compare and contrast, the other middleware also have their own
problem in some extents.
In experiment part, since no permission is given to install new JAVA web services
development package in our laboratory, the experiment could only be carried on at a
local network. Two laptops working system only represented the generally testing
system. Though the experiment method is designed carefully, the key problem is that
it is not related to a real database system. The main reason is time limitations and
human limitations (More details are showed in appendix A). In addition, the
presentation tier is not related to the web page. The author believes that the key
technologies of middleware are the application server and the client program. The
DOS interface can directly show the key idea of whole experiment aims. An
interesting point should be mentioned here is that the RMI experiment can run in our
laboratory. In this aspect, we know that the RMI technology is a mature technology. It
is convenient to realize in lab. (At least, it is accepted in our school.) The new
middleware software, including the .NET, Sun-ONE and even JWSDP, still has not
been tested in our university up to now. It can be also claimed that Web Services
technology is not popular or mature since it is not widely accepted by academic
institutions. (About the experiment result and conclusion, please see 4.5 for more
details)
In platform part, the comparison is limited too. (Please see 5.5 for more details)
The last but no the least problem is that there exists an amount of web application test
tools such as Borland® Optimizeit™ Server Trace, Microsoft's Web Application
Stress Tool (WAS), Quest Software's Benchmark Factory, RadView's Web Load 5.0
etc. Most of them can stimulate multi-user using web application and determine the
successful rate and bottleneck of the services, such as providing multithreaded testing
and reliable performance statistics. [61] However, only the WAS is free for
downloading. What is worth noting here is Borland® Optimizeit™ Server Trace,
which is a complete performance-testing tool of J2EE applications. For the time
limitation, I cannot adopt them in this project. The conclusion would be more
subjective if they were applied. [65]
In all, the whole comparison solutions can expose the different advantages and
disadvantages of different middleware technologies in a special way.
6.3 Conclusion
From the literature research above, we can make a conclusion seriously that the
distributed system’s new trends should be XML web service for its unique rationale
and its main supporter should be JAVA of SUN and Microsoft’s .NET. To familiarise
the detail about this area and obtain personal experience and finding, there still is a
long way to go. What follows is the summarization of RMI and Web Services.
6.3.1 RMI
RMI performs better than Web Services in the experiment comparison, but not in
theory comparison way. The advantages of Java RMI are pure language and good
crossing platform. “Write Once, Run Anywhere” makes it very popular in the past.
Java distributed object technology, commonly referring to RMI and EJB. RMI
provides the ability that one Java object invokes another Java object’s methods. It
only supports primary distributed object’s mutual operation similar with the
traditional RPC. Sun Company exploits EJB based on RMI and EJB frame which
provides all kinds of support distribution object computation services such as remote
invocation, security, transaction, permanence and life cycle management based on
Java server module model. [26]
6.3.2 The disadvantage of web services
1 From XML
Some disadvantages of web services come from the XML because most of the
applications are based on XML. Not only the advantages but also the disadvantages
are derived from XML. To be or not to be, it is a question.
1.1 web services occupy a plenty of CPU resource. XML data must be dealt with in
several stages before it is used by a system. Firstly, it needs be validated to check if its
data fit to the XML formulations and the DTD or Schema. Secondly, it needs be
parsed to get each item. Finally, XML data is an expensive way to exchange binary
data since there are many characters of tag to carry out each time.
1.2 web services occupy most of memory resource. When parsing the XML, it will
generate a mass of temporary memory objects, especially when it deals with DOM
object. Those mass temporary objects are natural burden for JAVA, which is a
language able to recycle the memory automatically. In each interval, the memory
32
recycling process is operated by temporary objects. As a result, the system
performance will decline. Some other web services (axis), however, adopt SAX to
decrease the amount of memory dramatically. [34]
1.3 Web services occupy amount of network resource. The amount of XML data
exchange is more than binary protocol (RMI/IIOP). This extra consumption can
give opposite effect when the network resources are intense or the net transportation is
busy.
2 From Web Services
Besides XML, web services itself also has some limitations.
2.1 up to date, the web service is a stateless service. It means that the service does
not store any invoker’s information. This nature comes from Web Services, which
provide the communication standard for applications and general dynamic services for
enterprises. The web services do not fit for the session-based method invocation and
complicated transaction. The argument opinion is that some web services products
(WASD) can store session information to make a stateful service and realize the
remote interface. Furthermore, it transfers the handle of remote object in session.
Client side can manipulate remote objects. [63] Those ideas are not difficult to realize
in theory way since any data, include session ID and transaction ID, can be transferred
in XML data form. Those Ids may realize the stateful service and transaction
processing in technology view. However, those functions are scared of the lack of
supporting standard and current WSDL can’t realize them. Inside enterprises, you may
use this special function voluntarily and define your personal session protocol since
the communication of service and the service invoker is under your control. However,
if you publish the service onto Internet, other applications may not recognize your
unique function. In addition, the data binding exists some scarcity.
2.2 the exchange of binary data and XML data often lost some semantic. Web
services need an exchange between the binary data and XML data since every datum
is transferred in XML style. The binary data, however, are not always conventionally
represented by XML. Furthermore, not all JAVA objects can be represented by XML.
(Even it can be realized well in .NET)
2.3 higher technology skill and longer study curve. Each product of web services
has a luxuriant tool and generates client side applications according to the definition
of web services (WSDL). It can easily pack the general service application into a web
service. In this point, each web service manufacturer announces that his platform is
easy to use without knowing the knowledge of XML. The user can publish Web
services in 15 minutes without knowing the WSDL UDDI SOAP etc. Those
advantages, however, are good for the simple Demo but not for the real applications.
To design the infrastructure and solutions scheme and regulate the performance,
according to idiographic applications, needs complete understanding of the every
aspect of web services.
6.3.3 The advantage of web services
Those disadvantages are upsetting. But in fact, there are many successful web services
33
applications and more and more develop manufacturers join in the group, which
proves the web services must be the new generation of major stream in web
information communication.
1 Web services are good for go through the firewall.
In general WAN and Internet applications based on RMI/IIOP with a binary protocol
always encounter a big trouble, firewall. The web browser of client is often behind the
firewall. Most firewalls only permit applications to connect with HTTP. If the client
inside the firewall connected the RMI/IIOP application port outside, the security
policies should be changed into a new way that client can access the ports except port
80(HTTP port). It will be more complicated if the RMI/IIOP application server is also
inside a firewall since there will be two firewalls to cross. The XML based on
heterogeneous platform is an inter-platform and inter-language data representing
method. Further more, the HTTP is a general protocol. Those make the web services
natural fitted for the heterogeneous platform applications. For example, the client
sides including various platforms such as JAVA applications or VB and COM
applications wish to invoke the service. There are two choices. One is to code
different API for different platforms and languages. The other is the Web Service,
which solves all problems in a single way.
2 Web services are good at security.
People believe that web services are weak at security because it exposes the internal
resource to public. However, the improving and generating of protocols, such as
SOAP, bring the web services into a very good security environment. Furthermore, the
web services can and easily use the various mature HTTP-based security technologies
since Web services use HTTP as the transport protocol.
3 Web services are good for EAI (enterprise application integration).
Most enterprises have various application systems that are developed by different
software manufacturers in different CEO-period. There are not only different
platforms and systems but also different development languages. The demand of
modern enterprise information systems asks for the interaction and communication
between applications. To protect the original investment, however, reusing the
carry-over systems is also a key task. Since the old systems always run on
heterogeneous environments, the cost of EAI is very expensive. The measure of web
services will drop the price of EAI. Not only the feature of platform and language
independent but also the development tools in different platforms and environments
always make sense.
4 Web services are good at enterprise application integration.
When an enterprise develops a new system, how to integrate other existed systems
should be considered. Invoking functions and functions being invoked should be kept
in mind. Using web services as the interface can keep a loupx-coupled relation with
other systems and a good scalability.
34
5 Web services are good at the B2B of an industry.
The business of a single industry is familiar. So it is easy to form a standard inside an
industry. The enterprise of an industry can keep the promise. However, how to
implement the service and what to provide are depended on the enterprises themselves.
For example, the balance service of telecom operation enterprise and the transfer
service of bank could form an industry standard and publish in UDDI. However,
different enterprises may choose different platforms to implement the service.
6.4 Summary and Suggestion
Once the web services are used broadly, the different services will be dynamic found
and located. It will provide various information interaction styles in different
equipments that will change the business pattern. Client can use the mature functions
for supporting better services. For examples, the Google engine can be used for web
services. It means that we can easily invoke the powerful Google search engine in our
applications. It looks like one part of our applications. [34]
All in all, it is good to stand up on other’s shoulder to see the big picture. Facing the
Web services, there are still many things to do.
References:
[1] Kurt Geihs. Middleware Challenges Ahead. IEEE Computer Magazine, 34(6): 24-31, June 2001.
[2] Java©, (2003), Java Remote Method Invocation (RMI), URL: http://java.sun.com/products/jdk/rmi/ [7th May
2003]
[3]
IBM©,
(2003),
Web
services
an
overview,
URL:
http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/infocenter/was/0408.html [7th May 2003]
[4] w3c©, (2002), Web Services Architecture W3C Working Draft, URL: http://www.w3.org/TR/ws-arch/#basic
[7th May 2003]
[5] Andrew S. Tanenbaum, Maarten van Steen, (2002), Distributed Systems: Principles and Paradigms,pp 2
[6] Coulouris, Dollimore and Kinberg, Distributed Systems: Concepts and Design, Third Edition 2001
[7] Peter M Dew, (2003), Virtual Working Environment, lecture slides 3, Introduction to Distributed Computing
and Information Sharing.
[8] Andrew S. Tanenbaum, Maarten van Steen, (2002), Distributed Systems: Principles and Paradigms , pp 90
[9] School of Computing, (2003), MSc Projects, URL: http://www.comp.leeds.ac.uk/mscproj/ [7th May 2003]
[10]
Microsoft@2003,
Defining
the
Basic
Elements
http://www.microsoft.com/net/basics/whatis.asp [17th May 2003]
[11]
Jerome
Kuptz,
(2001),
.NET
Framework
http://hotwired.lycos.com/webmonkey/01/02/index3a.html [17th May 2003]
of
.NET
Overview,
,
URL:
URL:
[12] Microsoft@2003, What Is the Microsoft .NET Framework?,
URL:
http://www.microsoft.com/net/basics/framework.asp
[19th May 2003]
[13] Daniel Rubiolo, J.D. MEIER, Edward JEZIERSKI, Alex MACKMAN, What is Microsoft® .NET? ,
Microsoft .NET Explained. pp1
[14] Daniel Rubiolo, J.D. MEIER, Edward JEZIERSKI, Alex MACKMAN, Paradigm Shift to Distributed
Computing Over the Internet, Microsoft .NET Explained.pp13.
[15] Daniel Rubiolo, J.D. MEIER, Edward JEZIERSKI, Alex MACKMAN, Why Microsoft® .NET?, ,
Microsoft .NET Explained, pp31
35
[16] International Systems Group, Inc, (Feb. 1997), Middleware White Paper
[17]Jan Newmarch, (2003), Distributed programming in JAVA,
[3rd Aug 2003]
URL: http://jan.netcomp.monash.edu.au/distjava/
[18] W3C, (2000), Simple Object Access Protocol (SOAP) 1.1,
URL: http://www.w3.org/TR/SOAP/ [3rd Aug 2003]
[19] HuanZhong, Cai, (2002), Web services basement, URL:
http://sun.cis.scu.edu.tw/~nms9115/articles/delphi/WebServices/WebServices1.htm
[20] Ws-c.org Forum, (2003), Comparison Table,
URL:
http://www.ws-c.org/forum/cgi-bin/topic.cgi?fo [3rd Aug 2003]
[21] Digital Earth, (2003), Why Web Services, URL:
http://www.digitalearth.net.cn/GISRelatedITIssues/Web%20Service/whyWebService.htm [3rd Aug 2003]
[22] MicroSoft, (2003), .NET Application Architecture Panel Discussion: Tech Ed 2001, URL:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch10.asp [3rd Aug
2003]
[23] CSTC, (2003), the Web App Server testing,
URL:
http://www.cstc.org.cn/show_article.asp?id=24 [3rd Aug 2003]
[24] Sun, (2003), JAX-RPC,
URL: http://java.sun.com/webservices/docs/1.0/tutorial/doc/IntroWS6.html [3rd Aug 2003]
[25] Middleware, Testing Report of J2EE and .NET
URL: http://www.middleware-company/j2eedotnetbench [3rd Aug 2003][26]Kim Topley,
Services in a NutShell, O’Reilly, Chapter 2
[27Java, (2003), RMI, URL:
(2003) , Java Web
http://java.sun.com/j2se/1.3/docs/guide/rmi/index.html [3rd Aug 2003]
[28] JGURU, (2000), Fundamentals of RMI, URL:
[3rd Aug 2003]
http://developer.java.sun.com/developer/onlineTraining/rmi/
[29] HP, URL: http://www.hpmiddleware.com/downloads/pdf/espeak_webservices.pdf
[30]
W3C,
(2002),
Web
Services
Architecture
http://www.w3.org/TR/wsa-reqs#id2604831,[27/07] [3rd Aug 2003]
[31] W3C, (2003), Web Services Glossary, URL:
[32] Simon Phipps, (2003), Web Services, URL:
Aug 2003]
[3rd Aug 2003]
Requirements,
URL:
http://www.w3.org/TR/ws-gloss/#webservice) [3rd Aug 2003]
http://wwws.sun.com/software/learnabout/webservices/
[3rd
[34] Apache, (2003), Axis Introduction, URL: http://xml.apache.org/axis/index.html [3rd Aug 2003]
[35]Google API, URL:
http://www.google.com/apis/ [3rd Aug 2003]
[36] HuiHoo, (2003), Comparison of Client-Server Middleware,
URL: http://www.huihoo.com/middleware/compare.html [3rd Aug 2003]
[37] SUN, (2003), RMI definition,
URL:
http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-objmodel3.html [3rd Aug 2003]
[38] HuiHoo Forum, (2003), RMI SOAP, IIOP, URL:
Aug 2003]
http://211.99.144.3/forum/viewthread.php?tid=266 [3rd
[39] (uddi-china.org,2001)
[40] Roger Sessions (2001), J2EE vs .NET Platform, Two Visions for eBusiness, objectwatch INC.,
http://www.objectwatch.com/FinalJ2EEandDotNet.doc#_Toc511347196 [16th May 2003]
[41] Akhil sahai, sven graupner, wooyoung kim, the unfolding of the web services paradigm, HP laboratories,
URL:
[42]Xiao-Ming Ji, n-tier middleware framewrok, URL:
[43] M. Litoiu, Migrating to Web Services – Latency and Scalability , Proceedings of the Fourth International
Workshop on Web Site Evolution 2002, 13-20(2002).
36
[44] Java, (2003), The JavaTM Web Services Tutorial ,
URL: http://java.sun.com/webservices/docs/1.0/tutorial/doc/JAXRPC3.html [3rd Aug 2003]
[45] Hyperdictionary, (2003), the definition of J2EE,
URL: http://www.hyperdictionary.com/dictionary/Java+2+Platform%2c+Enterprise+Edition [3rd Aug 2003]
[46]Sun, (2003), J2EE FAQ,
URL: http://java.sun.com/j2ee/faq.html [3rd Aug 2003]
[47] SUN, (2003), Java Technology and Web Services, URL: http://java.sun.com/webservices/. [3rd Aug 2003]
[48] Jguru of SUN, (2003), the rationale of RMI at runtime,
URL: http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html#RunningAnRMISystem [3rd Aug
2003]
[49] SUN, (2003), Frequently Asked Questions,RMI and Object Serialization,
URL: http://java.sun.com/j2se/1.4.2/docs/guide/rmi/faq.html#domain [3rd Aug 2003]
[51] W3C, (2001), Web Services Description Language (WSDL) 1.1, URL: http://www.w3.org/TR/wsdl [3rd Aug
2003]
[50] W3C, (2000), Simple Object Access Protocol (SOAP) 1.1,
URL:
http://www.w3.org/TR/SOAP/ [3rd Aug 2003]
[52] hyperDictionary, (2003), definition of UDDI
URL:http://www.hyperdictionary.com/dictionary/Universal+Description%2c+Discovery%2c+and+Integration [3rd
Aug 2003]
[53]Service-Architecture, (2003), UDDI,
URL:http://www.service-architecture.com/web-services/articles/universal_description_discovery_and_integration_
uddi.html [3rd Aug 2003]
[54] UDDI.org, (2003),
the Evolution of UDDI, White Paper,
URL: http://www.uddi.org/pubs/the_evolution_of_uddi_20020719.pdf [3rd Aug 2003]
[55]OASIS, (2003), UDDI,
URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec [3rd Aug 2003]
[56]UDDI.org, (2000), UDDI technology white paper,
URL: http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf [3rd Aug 2003]
[57] W3C, (2003),
SOAP history, 10 of 27,
URL: http://www.w3.org/2003/Talks/0618-hh-wschk/slide10-0.html [3rd Aug 2003]
[58] W3C, (2003),
SOAP history, 11 of 27,
URL: http://www.w3.org/2003/Talks/0618-hh-wschk/slide11-0.html [3rd Aug 2003]
[59] Hyperdicitonary, (2003), SOAP definition,
URL: http://www.hyperdictionary.com/dictionary/Simple+Object+Access+Protocol [3rd Aug 2003]
[60] Webopedia, (2003), DCOM definition,
URL: http://www.webopedia.com/TERM/D/DCOM.html [3rd Aug 2003]
[61]Abraham Jacob,(2002), Load Test Tools Evaluation,
URL: http://61.144.123.55:8010/testmanager_pro/haisongbao/sqa/ltte.htm [3rd Aug 2003]
[62] Sun, (2003), JAX-RPC, Core Web Services API in the Java platform
URL: http://java.sun.com/xml/jaxrpc/ [3rd Aug 2003]
[63]Systinet.com, (2003), Disadvantage of Web Services, URL: http://www.systinet.com. [3rd Aug 2003]
[64] Developer’s IQ, (2003), Will .NET Kill Java?,
URL: http://www.developeriq.com/Magazinestories/01aug13netvsjava.php3. [3rd September 2003]
[65] Borland, (2003), Optimizeit Server Trace, Complete performance solution for Java,
URL: http://www.borland.com/opt_servertrace [3rd September 2003]
37
[66] OMG, (2003), the history of CORBA,
URL: http://www.omg.org/gettingstarted/history_of_corba.htm [3rd September 2003]
[67] WEDI.org, (2003), Workgroup for Electronic Data Interchange,
URL: http://www.wedi.org/
[3rd September 2003]
[68] W3C, (2003), Extensible Markup Language (XML) 1.0 (Second Edition),
URL: http://www.w3.org/TR/REC-xml [3rd September 2003]
[69] Microsoft, (2003), Microsoft Message Queuing (MSMQ) Center
URL: http://www.microsoft.com/windows2000/technologies/communications/msmq/default.asp [3rd September
2003]
[70] IBM, (2003), WebSphere MQ (formerly – MQSeries)
URL: http://www-3.ibm.com/software/integration/wmq/
[3rd September 2003]
[71] Sun, (2003), A Simple Java Web Service Example,
URL: http://java.sun.com/webservices/docs/1.0/tutorial/doc/JAXRPC3.html [3rd September 2003]
[72] Sun, (2003), Java API for XML-Based RPC (JAX-RPC),
URL: http://java.sun.com/xml/jaxrpc/ [3rd September 2003]
[73] Sun, (2003), Java API for XML Messaging (JAXM),
URL: http://java.sun.com/xml/jaxm/ [3rd September 2003]
[74] Microsoft (2003), Getting started in.NET,
URL: http://www.microsoft.com/net/ [3rd September 2003]
[75] Sun, (2003), Java 2 Platform, Enterprise Edition (J2EE),
URL: http://java.sun.com/j2ee/ [3rd September 2003]
38
Appendix A: Reflection on Project Experience
In review whole project process, everything comes back in front of me. The project
preference form made everyone little nervous on February. It is not only about the
course itself but also the fate. What you are and what the school thinks about you.
Since I use to do consulting work and will continue to do IT consulting in future, I
choose the Web services project. It is a new technology, full of fantasy. Further more,
it is the highest-level information systems up to now and related to my major,
Information systems. Our course, virtual working environment (VWE), also illustrates
some aspects about this field. Then I met Nick Efford, my supervisor in the next
month. He is a very smart man, full of energy. I heard that he is the tough man in this
field. So, I felt lucky. When we met each other in his office, we began to talk about
my research. After serious thinking, we make sure the direction should be the
comparison of middleware technology. Consequently, it was the plan and the
literature review before June. It is a pity that I had to spend much time concentrating
on my final examination instead of the project on May and early June. The interim
report made me hurry up every day. Whatever happened, we kept on moving. After
confirming the plan, I began the formal project stage on June. In this stage, I began to
meet the wonderful technology in the world. Microsoft, Sun, IBM and countless
companies became more focused. Web services, RMI, DCOM, and CORBA
surrounded me day and night. I spend much of my time and energy into them. From
the beginner to the expert level, the literate articles made me exciting. The .NET and
J2EE like two familiar friends. They quarreled every minute. In July, I tried to
integrate them in my experiment. However, I cannot control so many new things. So I
concentrated on JAVA world. The main idea is that it is free for the developer.
Unluckily, I lost my way in the SunONE5.0 platform because it is the newest trial
version. No much material related to it, I struggled for nearly one month. Luckily, I
meet the JWSDP1.2 and J2SDK1.4.2. They are unreasonably easy. When I contact
Nick again, he gave me the new command to make the things simple. That is great. I
finish my experiment in half month. Finally, this report was generated.
To make a conclusion, there are many lessons to learn.
Firstly, it is time. Everything is time. Time is the single way RMI. This Web service is
onetime consumption. Personally, I think that one-year taught postgraduate study is
too tough for me. It is not only the course itself, but also the language. Unlike my
Indian classmates who also come from Asia, we seldom speak English in our
homeland. That made it triple hard for us to understand the lecturer’s word and the
coursework. In the beginning of project, I rarely spent time on project because it is
also the time to fight the examination. Furthermore, when I did the literature research,
most of my time was spent on the semantics not the project itself. My personal idea is
maybe half year longer is better than now. It is deserved because it is Master degree
project. (My last Master degree dissertation in china cost me one year.)
Secondly, it is the project plan. I changed my plan several times. The reason was that I
had not such technology experience before. Although I had computer-related working
experience, most focusing on code not the management. But now, I had experience. If
once more, I can do it better than this one. To implement the plan, I spent too much
time on the background research and the higher level IDE learning. For example, the
SunONE5.0 and VS.NET really waste my time to be familiar. Next time, I will take
the easy one to finish the task firstly and improve it in future. (So did the Microsoft)
Thirdly, it is the contents. I guess that I chose the difficult thesis. It is the comparison
of Middleware technology. The contents should include RMI, Web Services,
J2EE, .NET and Comparative technology. It looks like three or five new courses for
me. The technology is the newest. The development tools are hardly to get and to be
used. When I gave up the SunONE5.0 and change into JWSDP1.2 in my experiment,
it is nearly August. The JWSDP1.2 tutorial is not corresponded to the development
package until August. J2SDK1.4.2 met me in the same way. In fact, I began to learn
how to test software and systems in July. If there were more time, I could do my
project better than this one, definitely.
Finally, it is the human resource. The most important resource is not the technology. It
is human being. When I felt confused about my project, I always got new air from my
supervisor not the books, who is the expert of this field. The conclusion of this point
is that if you meet the problem, please ask your consultant as soon as possible. It
saves your time and energy. (It also applies to my future job.)
In conclusion, I have learned many new things from this project. Not only the
technologies but also the project management had given me many new thought and
idea. I hope they will accompany me in my future job or research.
40
Appendix B: Copy of the Objectives and
Deliverables Form
Appendix C: Copy of the Interim Report
1 Copy of the Marking Scheme
2 Copy of the header sheet for the marked Interim
Report,
3 Copy of the comments from the assessor.
Appendix D The PROJECT PLAN
Project Plan of scs2hcl (2003MAY)
Completed Days
5/8
5/18 5/23 5/28
26
6/2
6/7
6/12 6/17 6/22
6/27
7/2
7/7
7/12
7/17 7/22 7/27
8/1
8/6
8/11 8/16 8/21
16
6/20
2.Design and Experiment
5/8
1.Background Research
5/13
Remain Days
0
45
7/20
3.Write Up
0
25
8/15
4.Revision
44
0
16
8/26 8/31
9/5
Appendix E The LINK for PROJECT LOG
http://csiis.leeds.ac.uk/scs2hcl/mscproject/index.htm
http://www.personal.leeds.ac.uk/~scs2hcl/MSCPROJECT/