Comparisons of Middleware Technologies in JAVA … of Middleware Technologies in JAVA World Author: ... The History of Web Services ... Middleware research and development has reached

I

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.

II

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.

a

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

b

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

1

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

2

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.

3

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

4

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.

��

��Workgroup

ServersClients Mainframe

Message Passing and Remote Invocationto enterprise-wide resources

SecurityDirectory

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

5

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

6

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

7

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

8

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]

9

.

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.

Discovery Agencies

Service Description

Service Requestor

Service Provider

Service

Service Description

Find

Interact

Publish

10

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,

11

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)

12

Table 3.1 The Comparison of RMI and Web Services [17][35]

RMI Web Services

Data representation (what is moved)

Java Marshalled Object SOAP

Transport (how it is moved)

JRMP (Java remote method protocol)

various, usually HTTP

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, not Visual Java)

Java, .NET, Perl

Language paradigm Method call Procedure call

Remote reference Proxy object URL

Synchronicity *1 Synchronous Synchronous

Garbage collection *2

Yes 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

13

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 Framework

Component

Model

Communication

Protocol

Interface

Description

Service

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

14

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]

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

Client Program Server Program

Stubs & Skeletons

Remote Reference Layer Remote Reference Layer

Stubs & Skeletons

Transport Layer

RMI System

15

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]

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

Service Runtime System

Web Service Client

Service Runtime System

Web Service Endpoint

SOAP

HTTP

Web Service Invocation

Publish Import

Client Side Server Side

WSDL Document

16

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.

17

Looking up and connect latency test method in the RMI program, ��

��

� �� !�"##"$�� %&'$"#� ��(��"��

��)�*��

��+�� !��)�*,��

��

Searching time and connect latency test method in the Web Services program.

��

�� - �� (��./�!�� /01��

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

Machine/CPU # of CPUs

Memory Disk Software

1 DELL Latitude C40

1 256M 30G Windows XP; JWSDP1.2 J2SDK1.4.2

Table 4.2 Application Server Configuration

Number of clients


Memory Disk Software

1 TOSHIBA Satellite 2430-402, P4 2.53G

1 512M 40G Windows XP; JWSDP1.2 J2SDK1.4.2

Table4.3 Router configuration Number of clients


Software

1 Binatone ADSL 2000 Ethernet & USB Router

1 Build-in

18

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.

19

0

10 0 0 0

2 0 0 0 0

3 0 0 0 0

4 0 0 0 0

5 0 0 0 0

6 0 0 0 0

7 0 0 0 0

8 0 0 0 0

9 0 0 0 0

10 0 0 0 0

1 2 3 4 5 6 7 8 9 10 Avg.

Times

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.

0

10 0 0 0

2 0 0 0 0

3 0 0 0 0

4 0 0 0 0

5 0 0 0 0

6 0 0 0 0

7 0 0 0 0

8 0 0 0 0

9 0 0 0 0

1 2 3 4 5 6 7 8 9 10 Avg.

T imes

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

20

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

21

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 Web Services - / Connection Latency 1.3976 0.0547 1.3429 SayHello() average Latency 2.5615 8.4067 -5.8452 Sum() average Latency 2.0123 8.0691 -6.0568 SayHello() Latency * 3.9591 8.4614 -4.5023 Sum() Latency ** 3.4099 8.1238 -4.7139 Gap latency *** 0.5492 0.3376 0.2116 Memory Consumption 27M 66M -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.

22

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.

��RRMMII

��11 DDiirreeccttllyy CCoonnnneecctt ppeerrffoorrmmaannccee bbeetttteerr tthhaann WWeebb SSeerrvviicceess

��22 MMaattuurriittyy tthhaann WWeebb SSeerrvviicceess

��WWeebb SSeerrvviicceess

��11 nneeww tteecchhnnoollooggyy

��22 ggoooodd ffuuttuurree oonnllyy ssiinnccee iittss rraattiioonnaallee

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]

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]

24

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.

25

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.

26

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]

VB C++ C# JScript … Common Language Specification

ASP.NET Windows Forms ADO.NET and XML Base Class Library

CLR Windows COM+ Services

V

isual Studio.NE

T

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

27

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

Support technologies

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

28

Presentation tier technologies

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

Middle tier technologies

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 Context

JAAS

Message Queue API MSMQ JMS 1.0

Asynchronous components

Queued (COM+) Message driven beans (EJB 2.0)

Naming and Directory Service

ADSI 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 DB connectivity

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,

29

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)

Forte for Java (Sun) WebLogic Workshop (BEA) JDeveloper (Oracle) VisualAge for Java (IBM) Visual Café (WebGain)

Visual Stdio.NET

30

Type of Technology

Standard Product

Vendors 30+ 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]

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

32

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

33

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

34

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.

35

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 of .NET , URL: http://www.microsoft.com/net/basics/whatis.asp [17th May 2003]

[11] Jerome Kuptz, (2001), .NET Framework Overview, URL: http://hotwired.lycos.com/webmonkey/01/02/index3a.html [17th May 2003]

[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

36

[16] International Systems Group, Inc, (Feb. 1997), Middleware White Paper

[17]Jan Newmarch, (2003), Distributed programming in JAVA,

URL: http://jan.netcomp.monash.edu.au/distjava/ [3rd Aug 2003]

[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: hhttttpp::////wwwwww..mmiiddddlleewwaarree--ccoommppaannyy//jj22eeeeddoottnneettbbeenncchh [3rd Aug 2003][26]Kim Topley, (2003) , Java Web Services in a NutShell, O’Reilly, Chapter 2

[27Java, (2003), RMI, URL: http://java.sun.com/j2se/1.3/docs/guide/rmi/index.html [3rd Aug 2003]

[28] JGURU, (2000), Fundamentals of RMI, URL: http://developer.java.sun.com/developer/onlineTraining/rmi/ [3rd Aug 2003]

[29] HP, URL: http://www.hpmiddleware.com/downloads/pdf/espeak_webservices.pdf [3rd Aug 2003]

[30] W3C, (2002), Web Services Architecture Requirements, URL: http://www.w3.org/TR/wsa-reqs#id2604831,[27/07] [3rd Aug 2003]

[31] W3C, (2003), Web Services Glossary, URL: http://www.w3.org/TR/ws-gloss/#webservice) [3rd Aug 2003]

[32] Simon Phipps, (2003), Web Services, URL: http://wwws.sun.com/software/learnabout/webservices/ [3rd Aug 2003]

[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: http://211.99.144.3/forum/viewthread.php?tid=266 [3rd Aug 2003]

[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).

37

[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]

38

[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]

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

40

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.

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

44

Project Plan of scs2hcl (2003MAY)

5/8

6/20

7/20

8/15

26

0

0

16

45

25

16

0

5/8 5/13 5/18 5/23 5/28 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 8/26 8/31 9/5

1.Background Research

2.Design and Experiment

3.Write Up

4.Revision

Completed Days Remain Days

Appendix E The LINK for PROJECT LOG http://csiis.leeds.ac.uk/scs2hcl/mscproject/index.htm

http://www.personal.leeds.ac.uk/~scs2hcl/MSCPROJECT/

Comparisons of Middleware Technologies in JAVA … of Middleware Technologies in JAVA World Author: ... The History of Web Services ... Middleware research and development has reached

Documents