Table of Content - grid computing - Binghamton University

toaststicksrifleΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 5 χρόνια και 2 μήνες)

384 εμφανίσεις





M
OBILE

C
ODE

E
NABLED
W
EB AND

G
RID

S
ERVICES












BY




P
U

L
IU



M.S., Computer Science and Engineering,

Wuhan University, 199
7













DISSERTATION



Submitted in partial fulfillment of the requirements for

the degree of Doctor of Philosophy
in Computer Science

in the Graduate School of

Binghamton University

State University of New York

2006




© Copyright by Pu Liu 2006

All Rights Reserved























Accepted in partial fulfillment of the requirements for

the degree of Doctor of

Philosophy in Computer Science

in the Graduate School of

Binghamton University

State University of New York

2006




Michael J. Lewis _______________________________________ August

8
, 2006

Department of Computer Science, Dissertation Advisor


Leslie Land
er
_________________________________________ August

8
, 2006

Department of Computer Science
, Chair of
Committee


Madhusudhan

Govindaraju

______________________________ August

8
, 2006

Department of Computer Science


Kenneth Chiu
______________________
___________________ August

8
, 2006

Department of Computer Science


Fernando Guzman

_____________________________________ August
8
, 2006

Department of Mathematical Sciences
, Outside Examiner






iv

Abstract

Web services provide a standard means to achieve i
nteroperability between different
software applications in a heterogeneous distributed environment.
T
he Web
S
ervices
R
esource Framework (WSRF)

has re
defined

Grid computing standards
, making

Web
services more
suitable

for Grid applications

by adding persist
ent state management
.


A
primary benefit of Web
and Grid s
ervices is that they provide

a uniform implementation
-
independent mechanism for

accessing distributed services.

However, it is still difficult to
build, deploy, and
evolv
e such services. D
ifferent W
eb
or Grid s
ervices
containers
are

implemented in different programming languages, with

different constraints and
requirements placed on the

programmer.

The research described in t
his
dissertation takes
a significant first step toward

"write
-
once deploy
-
an
ywhere"
Web
and

Grid services
,

by
enabling mobile code for different Web and Grid services containers
.
The term “mobile
c
ode


refers to passive code segments
that can be

dynamic
ally

deploy
ed

into a variety of
hosting environments.

The basis of
this

approac
h is the design and definition of a
common intermediate language
, called X#,
for the
representation

and transmission of
mobile code.
T
hree
Web services

containers (
namely,
Tomcat, ASP.N
ET

and
a
gS
OAP

based C++ container
),

and two Grid services containers
(
namely, GT4
and

WSRF.NET
)
now

support
dynamic
mobile code

deployment through a standard Web service
deployment interface
.
C
ontainer
s

receive

the
mobile X# code

and then

generat
e

container
-
specific native code in different languages, without exposing these
details to
applications and Grid services programmers.

The dynamically deployed mobile code
can

access state managed by the hosting container,
can

utilize functionalities exposed by
statically deployed services, and
can

communicate with
other

mobile code m
odule
s,






v

running
either in the same container or
in
different containers.
A

performance study
shows
that
the newly

deployed mobile code
can
run as
nearly
efficient
ly

as it would if it
had been deployed statically
, through container
-
specific mechanisms
.

The

resulting

software systems enable uniform dynamic deployment of the same code into several
different container
s

written in different languages, including C#, Java, and C++. This
reduces the burden on service programmers, facilitate
s
interoperability, and p
otentially
increases the impact of service code by allowing it to run in a larger number of different
containers.








vi

To my wife Yuan Zhou,

my father Shaoliang Liu,

my mother

Rengui Liu,

my father in law Xiqi Zhou,

my mother in law Penglian Chen,

Mr.
Jianpe
i Hu,

and
Mrs.
Yaxin Zhang







vii

A
cknowledgement

In a man

s life, five years are not short, especially when they are used to do one thing.
For me, it is impossible to get my Ph.D after five years


study without the
guidance

and
support of my advisor, Dr. Micha
el J. Lewis. I sincerely appreciate his
invaluable time
and effort. I would also like to thank my Ph.D committee members
for their helpful
suggestions

on
my thesis work. They are
Dr.
Leslie C. Lander,

Dr.
Madhusudhan

Govindaraju
, Dr.
Kenneth Chiu
, and Dr.
Fernando Guzman
.


During the past five years, I have be
en very lucky to make a

lot
of
friends

who

are
always around to encourage me and support me. They are Jikai Li,
Sihong Ma,
Zhen
Chen, Jiaming Zhong,
Zhihui Zhang,
Qixiong Zhen, Jingzhou Hua,
Yao Jian,
Xiaoming
Li, Xiaozhou Wei,
Hongkun Zhao,
Yiyao Lu, Ke Liu, and Wanjing Zhang.
In addition, I
want to thank
to

Michael R. Head,
Prabhakar Muthuswamy
, Xin Ling, and
Sameer Tilak

for many useful technical discussions.
A
cknowledgements
also
go to

Mr.
George We
isert
,
my English tutor, who
helped
and is helping
me adjust to
the
local
culture.


I
am also very grateful
to

Mr.
Yonggang Hu, my manage
r in Platform Computing
Inc. In his group, I got the chance to work with many
intelligent

people for
top
industry
soft
ware products.

Special thanks go to my first friend in Canada, Mr. Hao Zhou.


At last,
I would like thank my wife
,
my

parents
, my parents in law,
uncle Hu
, and
aunt

Zhang

for everything they did for me
. Their love

is always the source of
my
impetus

for th
e future.








viii

Table of Contents

1.

Introduction

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

1

1.1.

The Problem

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

2

1
.2.

A Solution

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

4

1.3.

Thesis Statement and Contributions

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

8


2.

Related Work

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

10

2.1.

Mobile Code and Web Services

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

10

2.2.

Mobile Code Representation
................................
................................
.............

12

2.3.

Web and Grid Services Deployment

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

15

2.3.1 Java Containers

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

17

2.3.2 ASP.NET XML Web Services

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

18

2.3.3

C/C++ Apache Axis

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

19

2.3.4 Globus Grid Services Container

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

19

2.3.5 Deployment Comparison

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

20

2.4.

Web and Grid Services State Management

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

22

2.5.

Web and Grid Services Invocation

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

25

2.6.

Summar
y of Related Work

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

27


3.

Mobile Code Enabled Web and Grid Services

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

29

3.1.

X# Design

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

32

3.2.

WS
-
C Design and Parsing

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

37

3.3.

Container Interface
................................
................................
............................

40

3.4.

Container Design

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

42

3.5.

Summary

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

49


4.

Limitations

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

50


5.

Examples

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

53

5.1.

Using Mobile Code

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

53

5.2.

Ring Based Election Algorithm

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

56

5.3.

A Second Example

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

61


6.

Performance Evaluation

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

64

6.1

Overhead

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

66

6.1.1

Intra Mobile Code T
esting

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

67

6.1.2

Inter Mobile Code and Static Web services Testing

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

68

6.1.3

Inter Module Mobile Code Calls Testing

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

69

6.1.4

Test Results for Local and Remote Containers

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

69

6.1.5

State Access Testing

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

79

6.2

Cost

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

82


7.

Summary

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

88







ix

References

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

89


Appendix A:
XSharp Schema

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

94


Appendix B: WS
-
C LL Grammar

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

101


Appendix C: Ring Algorithm

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

103

Appendix C.1: Client Program

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

103

Appendix C.2: WS
-
C Code
................................
................................
.........................

106

Appendix C.3: Generated Java Code

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

107

Appendix C.4: Generated C# Code

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

108

Appendix C.5: Generated C++ Code

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

109


G
lossory

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

115








x

List

of
Figures

Figure 1: System Architecture: Programmers write code in a high level language,
translate it into X#, and transmit it into any of sever
al X#
-
enabled containers, where it is
translated out into that container’s native code, and where it runs as a Web service.

......

32

Figure 2: In WS
-
C, mobile code can call statically deployed servi
ces in the same
container

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

38

Figure 3: In WS
-
C, mobile code can call functions defined in other modules deployed in
the same container
................................
................................
................................
.............

38

Figure 4: In WS
-
C, mobile code can call other modules deployed in different containers
via

invokeRemoteService()

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

39

Figure 5: Schema type of InvokeParams and InvokeResult

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

41

Figure 6: Schema type of
invokeRemoteService()

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

42

Figure 7: Overview of state management

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

43

Figure 8: gSOAP based C++ container

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

44

Figure 9: Ring structure

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

57

Figure 10: Generated Code in C#

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

60

Figure 11: Generated Code in C++

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

61

Figure 12: pseudo code of a typical EA

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

62

Figure 13: WS
-
C code for intra module testing

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

68

Figure 14: WS
-
C code for
testStatic()

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

68

Figure 15: WS
-
C code for int
er mobile code module calls testing

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

69

Figure 16: Linear Regression graph for
testIntra()

in Java
-
based container

..........

72

Figure 17:
Linear Regression graph for
testInter()

in Java
-
based container

..........

72

Figure 18: Linear Regression graph for
testStatic()

in Java
-
based container

........

73

Figure 19: Linear Regression graph for
testIntra()

in C++
-
based container

..........

73

Figure 20: Linear Regression graph for
testInter()

in C++
-
based container

..........

74

Figure 21: Linear Regression graph for
testStatic()

in C++
-
based container
........

74

Figure 22: Linear Regression graph for
testIntra()

in C#
-
based contain
er

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

75

Figure 23: Linear Regression graph for
testInter()

in C#
-
based container

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

75

Figure 24: Linear Regression graph for
testSta
tic()

in C#
-
based container

..........

76

Figure 25: From the data in Table 4, using function
staticFunc()

as the base,
overhead measured in percentage for different use cases in different containers

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

77

Figure 26: WS
-
C code for testing state access in the mobile code

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

80

Figure 27: From the data in Table 5, using function
staticFu
nc()

as the base, the
minimum and maximum percent overhead for different use cases of different sizes and
values of N in different containers

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

81

Figure 28: WS
-
C code for testing
installCode()
.

The same function body is
repeated with different function names.

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

83

Figure 29: From the data in Table 6, the times reported in milliseconds of
installCode()
for different sizes of WS
-
C code

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

84

Figure 30: From the data in Table 7, the file sizes for different languages

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

85






xi

List

of
Tables


Table

1: Deployment mechanisms in various Web and Grid service containers

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

21

Table 2 : Test results for local containers in different use cases, reported in microseconds.
Confidence interval ±∆ is

calculated with 95% confidence.

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

71

Table 3 : Linear Regression results for Table 2.

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

71

Table 4 : Test results for remote contai
ners in different use cases, reported in
milliseconds. Confidence interval ±∆ is calculated with 95% confidence

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

76

Table 5 : Testing results for remote containers in different use cases, repor
ted in
milliseconds. Confidence interval ±∆ is calculated with 95% confidence.

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

81

Table 6: Testing results for
installCode()

reported in milliseconds. Confidence
interval ±∆ is calculated with

95% confidence.

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

84

Table 7: The code size of WS
-
C, X#, and container specific code, reported in bytes.

.....

85






1

1.

Introduction

Web service
s

provide a standard means t
o achieve interoperability between different
software applications in a heterogeneous distributed environment

[83]
. XML and
standard Web protocols such as HTML and SOAP have made
Web service
s

robust,
extensible,

and independent of platform, language
,

and framework.


In
the
Web service
s

architecture, clients and services are loosely coupled
. A

contract first
well
-
specified interface
of

Web
services

eliminates
the
implementation
dependencies
between clients and
ser
v
ice
s
. This
allows

clients
to
invoke
Web service
s

from any client
-
side environment that supports the standard
Web service
s

protocols.
Clients can continue to use the services even if the service implementation is changed, as
long as the interface remains s
tatic. Clients can consume the service without
implementing resource allocation,
service instance management,
or other service
-
side
responsibility
.

T
he
Grid

c
omputing community

also
adopts

Web service
s

standards and
techniques as the basis for Grid applic
ations
[24]
. T
he
Web
S
ervice
s

R
esource
Framework (WSRF)

[57]

has re
-
defined

Grid

computing standards (previously OGSI

[78]
) to be compatible with
Web service
s

conventions and specifications.
Moreover,
after
some improvements,
WSRF
makes
Web service
s

more adequate for
Grid

applications

[25]
. In particular, p
lain
Web service
s

(as cu
rrently specified by the W3C) were designed
to be
stateless

and to send responses only back to the caller,

using a request
-
response





2

pattern

[83]
. In contrast, to scale well and to support a wide variety of diffe
rent and
meaningful high performance
Grid

applications, programmers must be able to store state
information between multiple coordinated calls, and to

coordinate
calls

without
centralized control.


WSRF
provid
es

the means within the
Web service
s

architectu
re to manage state.
In WSRF, a WS
-
Resource is

a composition of a
Web service

and a stateful resource

[70]
. The four WSRF specifications describe how to represent, manage, and group WS
-
Resources. Clients refere
nce the WS
-
Resource by a WS
-
Addressing Endpoint Reference,
and query or modify WS
-
Resources through Resource Property documents

[70]
.

Working
closely with
WS
-
Notification specifications

[73]
, WSRF
allows
clients to subscribe to
certain WS
-
Resources

and
if a change occurs in one WS
-
Resource, all subscribers are
notified.

The common perception is that
W
eb and
Grid

services

are implemented in Java
or .NET. Although these
two technologies are the most commonly used, they are not
necessarily the most suitable for Web and
Grid

services

in some cases. Because
Web
service
s

are most often used as part of a larger application, the
most appropriate
language
or environment
should
be

determined by the
requirements of the
high
-
level application.
This leads to
Web

and
Grid

services

written in Python

[61]
,
Perl

[84]
,
and other
languages, including

C

and
C++

[1]
[65]

.

1.1.

The Problem

This heterogeneity of
Web

and
Grid

s
ervice

implementations

in language, operating
system, and functionality

is a good thing, and sh
ould be encouraged. It allows
programmers to select environments that best meet their applications’ requirements.





3

However, it currently complicates matters for developers who want their services to run
in many different types of containers,

since d
ifferent

Web and
Grid

services

containers
require that the services they host be written in specific languages, to target particular
internal interfaces.

Therefore,
an

author of a Web or
Grid

service who wants that service
to run in multiple different container en
vironments must build the service differently for
each environment. With architecture heterogeneity, compilers can be used to build the
same high level language program into executables for each target environment. However,
there is no such tool to convert

the same Web or
Grid

service into implementations that
can run in different containers.
This is the problem that the research described in this
dissertation

intends to solve.


To make effective use of

Grid

environments, application

and service

code

should

be able to be deployed and moved within the
Grid
, based on the dynamic use of
Grid

resources. If a node or cluster that hosts some particular
Grid

service becomes over
-
utilized or unavailable, that service should move somewhere that can better accommodate

it, after considering the current load conditions. The new location of a
Grid

service
should not be restricted to only those sites and containers where the code is currently
installed and deployed. Otherwise, the adaptability and flexibility of
Grid

envir
onments is
necessarily restricted at deployment time (based on the initial locations of all code), and
Grid
s will not be able to make the best possible use of the vast
Grid

environment.

T
he extensibility of Web serv
ices

is based on
the e
xtensibility

of XM
L e
lement
s



new
WSDL
documents can
be extended from existing definition
s
.
But m
any current
models and environments require that both interfaces and implementations remain static
for the lifetime of a
Web
service; that is, once the Web service is published
, any change





4

to the WSDL
requires
a

brand

new service

[6]
[24]
.
D
ynamic deployment of services (in
the implementations in which it is supported) is handled by container
-
specific
mechanisms, and inter
operability between containers that implement the same
specifications is limited by practical implementation details.

This particular problem is
described in more detail in
Section

2.3.

In summary, models, specifications, and implementations conspire to li
mit the
movement, extensibility, and dynamic deployment of Web and Grid services. This is
especially true for heterogen
e
ous Web service environments, wherein a single container
type is not assumed.

1.2.

A Solution


The solution
described in this thesis contrib
utes to
"write
-
once deploy
-
anywhere"
Web
and

Grid

services
.
Essentially,
the interface for a “
Grid

services

virtual machine” allows
the generation of container specific native code in different languages, without exposing
these details to applications and
Grid

services

programmers. The burden instead falls on a
set of tools to automatically translate
the mobile code
into the appropriate code for each
different back
-
end service container.


This

solution does not assume that a single framework such as .NET or

JVM is
installed everywhere.
Such an assumption

would

undermine the benefits of Web services,
since
binary messaging
is generally
more efficient than XML
-
based Web services



Java

environments can
use RMI,
and
.NET

environments support

.NET remoting.

As
described in this thesis
, t
he basis of
the approach
to enabling mobile

code in
Web and
Grid

services

is the design and definition of a common intermediate language





5

for the expression and transmission of mobile code
1
. This

XML
-
based language
is named
X# (pr
onounced "X sharp").
T
hree
Web service
s

containers (
namely,
Tomcat

[80]
,
ASP.N
ET

[47]
,
and gS
OAP

[65]
),

and two
Grid

serv
ices

containers
(
namely, GT4

[23]

and

WSRF.NET

[45]
)
are augmented
with
support for
X#

mobile code
. Each container
runs a special service whose purpose is to accept m
obile X# code. The service then
translates the code out of X# and into the language appropriate to the container. For
Tomcat

and GT4
, this language is Java
;

for ASP
.NET

and WSRF.NET
, it is C#
; for
g
SOAP, it is C++.

The
resulting
container
-
specific code is
then compiled just as any
other new
Web service

that targets that container would be, and is installed at the
container. Therefore, once it has been installed and deployed, the mobile code runs as
efficiently as it would if it had been deployed "staticall
y."

This thesis
describes

a

ring
-
based distributed election algorithm

[12]

using the
mobile code approach
, and shows
how the same
piece of mobile code
can be effectively
and dynamically incorporated into these
very different containers
.
P
erformance testing
shows
that
mobile code can run as
efficiently

as if it were coded directly for the container
.

It is not
conv
en
ient

for

programmers to directly write their code in X#; instead,

they
should

use a high level lan
guage of their choice, and use a translator to map it into
the equivalent X# code. For illustrative purposes, and to handle simple mobile code
programs,
this
thesis introduces

the
WS
-
C language
.
WS
-
C is a
simple
r

variant

of C for
which an X# translator

has

been built
. Thus
,

programmers can write mobile code in
WS
-
C and translate it directly into X#.




1

A
lthough related, the notion of

mobile code


is not the same as
that of
mobile agents or
process mig
ration,

both of which imply the possible migration of state and the movement
of running instances.

Mobile code refers
to the dynamic deployment of passive code
segments into a variety of hosting
environment.






6

To be
effective for

stateful Peer
-
to
-
Peer computing

[10]

in
Grid

environment
s
,
the
solution described here

support
s

stateful mobile code
2

and provide
s

a
Web service

interface for
dynamically deployed
mobile
services

to communicate with
one an
other.
For
WSRF
-
based GT4 and WSRF.NET
Grid

s
ervice containers,
mobile code can
manipulate the stateful WS
-
Resource
s

managed by t
hose containers
.

F
or non
-
WSRF
Web service

containers,
such as Tomcat
,

ASP.N
ET, and our
g
SOAP
-
based C++
container,

the container

itself
support
s

mobile code

to access stateful information
.

The
resulting mobile code enabled
Web and
Grid

services

resemble fu
lly

functional objects,
with internal state and the ability to
directly
invoke the functions of other objects/services.
Together with dynamic deployment across multiple different interoperable containers,
this facility
allow
s

Web and
Grid

services

containe
rs to provide effective support for high
performance
Grid

applications.

Three

potential
distinct advantages can be gained from
the

approach

described in
this thesis
.

(1)
Container
-
independence
:
Web and
Grid

services applications can be written in
a contain
er independent way; the same high level service code can be automatically
translated and dynamically
incorporated

into multiple different service containers running
on top of different languages and platforms.

(2)
Uniform
Dynamic
d
eployment
:
M
obile code en
able
s

the dynamic deployment
of
new
Web or
Grid

service
s
.
There is no need to shut

down the whole container
or any
of its services,
while programmers update
service
s
.
Moreover, the mechanism for



2

Mobile code itself is a piece of passive code during transmission. Stateful mobile code
means
that
after mobile code is loaded into memory and executed, it can acce
ss
persistent
state
information, which is managed by
either by
the hosting container

or within the
service itself
.






7

deploying services dynamically


including the representation

of the code (in X#) and
the deployment interface in the container


is common across the various containers.

(3)
Moving code to data
:
Mobile code
can be
incorporated into the container
dynamically, and
can
run

local to the server, rather than in the clie
nt's address space. This
makes more fine grained Web or
Grid

service interfaces more appropriate, thereby
increasing the situations in which Web and
Grid

services

can be used.

Each of the above advantages
has

been enabled and tested for the research
descri
bed in this dissertation. In addition, at least two more advantages are enabled by



but not specifically utilized or tested for


this work. These additional advantages
include:

(4)

Distributed
workflow control
: Mobile code, encapsulating the process logi
c
and execution state, can enact workflow activities by moving to service providers and
interacting with them. The execution of workflow
can be

distributed

to multiple
mobile
agents
,

which can
cooperate to
execute

one workflow. There is no need
f
or

a centr
alized
execution environment.


(5)
Smart notification
:

C
lients can
install
mobile code
to fulfill the generation of
customized and sophisticated
notification. The mobile code that accepts the notification
can decide when and where to generate
the
notificat
ion event back to the
interested

client.

This thesis

represents
significant progress

toward write
-
once

deploy
-
anywhere
W
eb and
Grid

services
. It
support
s

s
tate management and peer
-
to
-
peer communication
,
which are necessary requirements for using Web and
Gr
id

services

as the basis for
middleware infrastructure to support high performance
Grid

applications.






8

1.3.

Thesis

Statement and Contributions


Thesis

statement
: Using
the
mobile code enabled Web

and
Grid

services

approach,

serv
ice

programmers can
write
m
uch

of
their
Web and
Grid

services

code
in a single
high level language program (in our implementation, WS
-
C)
,
and deploy
it int
o different
kinds of containers with varying

implementation characteristics
.

These services can then
run nearly as
efficiently

as if t
hey were coded directly for the container.

More specifically,
mobile code mechanisms represent approximately 3% to 21%
overhead on server
-
side functionality needed to make mobile code calls in fully
functional Grid services containers. This overhead is esp
ecially small considering that
Web and Grid service invocation times can be dominated by the cost of making a remote
call, and of carrying out the invoked service. Chapter 6 containers more details.

This dissertation comprises
the

design
and implementation

of X#,
complete
implementation

of the functionality in GT

4
.0

(Java), WSRF.NET

3.0

(C#), and g
SOAP

2.7.8
(C++)
,

a
n

implementation of the small
Web service

language called WS
-
C,
and
initial promising performance results.


The
contributions
of this
dissertat
ion

are:

(1) A framework to incorporate mobile code into
W
eb

and
Grid

services

infrastructure.

(2)
A f
ully functional mobile code
implementation

on top of GT

4
.0
,
WSRF.NET

3.0
,
and
g
SOAP

2.7.8
.

(3) A thorough performance study of mobile code
, which chara
cterizes the run
-
time cost of

dynamic compilation, dynamic invocation, and
state
management, and





9

demonstrates the overhead of using services built via mobile code, as opposed to those
written directly for the container.

(4) A
demonstration
of interoperabil
ity of mobile code in different containers.

(5)
T
he design and implementation
of a
prototype
C++
-
based

mobile code
container

for
Web service
s
.

Each of these contributions is described in more detail later in this document,
wh
ich is organized as follows.
C
hapter

2
discuss
es

related work, and
Chapter

3 describes
the details
of mobile code enabled Web and
Grid

services

including the design of X#,
WS
-
C, and container

support
.
Chapter

4
addresses
several

l
imitations
of

the

approach.
Chapter

5
describes

an examp
le of how to utilize
the

mobile code approach for
a

ring
-
based election algorithm

and discuss
es

the applicability of mo
bile code enabled Web and
Grid
s
ervices.

Chapter

6
presents performance results
, and

Chapter

7

summarizes the
dissertation
.






10

2.


Related Wor
k

The challenges of
the
mobile code enabled Web and
Grid

service
approach
include: (1)
how to design mobile code to
seamlessly integrate with
Web and
Grid

environment
s
;

(2)
how to
choose the
represent
ation for

mobile cod
e
; (3
) how to abstract
the
heterogen
eity

of containers
to support
dynamic deployment, loading, and execution
of
mobile code
across different languages and platforms;

(
4
) how to manage th
e state of mobile code;
and
(5
) how to allow mobile code

services

to communicate with
one an
other and
to
c
all
out directly to any Web or
Grid

service outside the hosting container.
T
his
c
hapter

organize
s

and describe
s

the
related work

accordingly.

2.1.

Mobile C
ode and
Web
S
ervice
s

To access a
Web service
, client programmers discover and obtain a description of that

service in the form of a WSDL
document
.
T
ypically, a stub generator then creates client
-
side stubs for accessing the remote service. The stubs provide access to the service by
sending requests to the remote server and fetching the results. Because the WSD
L file
and the SOAP communication protocol are both based on XML, the client is able to
acce
ss the
Web service

ubiquitously.

T
he interoperability and expressiveness afforded by XML
-
based
Web service

st
andards come at
the expense of performance

[36]
. A typical
Web service

invocation

and
corresponding response
,

either using RPC
-
oriented or document/literal mode,
require
serialization, communication, and de
-
serialization, in both directions. Clearly, this





11

associated

overhead makes remote
Web service

access significantly slower than a local
method call. If the client code could run in the address space of the
Web service

itself,
then the serialization and access could be much more comparable to that of a local
functio
n call. The overhead then would depend on the one
-
time cost to send, install, and
run the client's code, instead of the time to serialize and transmit the data associated with
however many calls the code contains. Potential performance improvements can be
achieved when clients make many calls, send lots of data, or both. This is the primary
motivation for mobile agents and mobile code
[7]
.


Web service
s

and mobile agents can be combined in two fundamentally diffe
rent
ways. Mobile agents can simply be utilized within
the

Web service
s

architecture, or
Web
service
s

can themselves be implemented to act and behave as mobile agents.

In the first category, for example, Maamar et. al.

[88]

use mobile agents to carry
out the composition and execution of
Web service
s

in parallel in a dynamic environment.
This helps overcome the drawbacks of composing
Web service
s

in a sequential multi
-
stage manner. Shonali et. al.
[2]

use mobile agents to select the most efficient
Web
service
s

for clients in a dynamic environment. In both cases, the
Web service
s

themselves
are not changed. Instead, the application simply utilizes them as just another of

its
components. In this sense, the
Web service
s

are complementing other separate and
disjoint mobile code mechanisms, not implementing or directly supporting them.

The work in the second category, including
that described in this thesis
, integrates
mobile

agents and
Web service
s

more closely, leading to "Mobile
Web service
s
." A
Mobile
Web service

can migrate between containers, and can interact with other existing





12

Web service
s

and clients. Its internal functionality helps determine when and where the
servi
ce migrates.

Fuyuki
[15]

proposes a general framework for Mobile
Web service
s
. The
prototype of this framework utilizes BPEL to specify the interactions with other
Web
service
s

or clients, and uses Java to imple
ment internal behavior. The resulting mobile
Web service

is dependent on the platform and limited to Java. The authors mention that
they are looking for a mechanism to achieve interoperability between mobile code and
different containers.

Maamar
[89]

uses an agent
-
based architecture to provide
Web service
s

to a
mobile device. To provide clients with seamless access to
Web service
s
, a
Web service

is
transferred from its host site to a mobile device and executes t
here. IBM Aglets

[8]

are
used to implement mobile agents for service invocation at resource sites, with Sun Java 2
Platform Micro Edition running on the mobile devices. Again, the resulting system
cannot be app
lied to non
-
Java
-
based
Web service
s
.

2.2.

Mobile
C
ode
R
e
presentation

S
imply introducing platform dependent or language dependent mobile code techniques
into
Web service
s

would undermine
Web service
s
' basis for success. Any such approach
should be independent of

language and container environment.

One approach

i
s to
write
mobile code in one language and then, on the server side,
to
translate
it
into
the

container
specific
language.

T
his
is a

one
-
to
-
one


language conversion approach, and t
here exist
many
automati
c

language translation systems.


The Java Language Conversion Assistant (JLCA)
[49]

is a tool that
allows
programmers
to convert

Java code to C#.
Harissa

[19]

provide
s

a compiler
to convert





13

Java byte

code to C
.

Semplice

[66]

is
a project
in the early stages of development
, which
allows programmer
s

to

compile
Visual Basic (
VB
)

source code into Java class files.

Demaine
introd
uced
a general method

for

automatic conversion of
C
pointers into
Java
references

[14]
.

The
main focus is on translating scienti
fi
c applications written in C
,
or
only
available

in C
,

such as
SuperLU. f2j
[17]

is a Fortran
-
to
-
Java converter

that

uses
C
as
an intermediate representation
.

T
hat is, it converts
FORTRAN

code into C, and
converts the result to Java.
But C p
ointers are completely avoided.

f2c
[68]

translates
Fortran 77 into C or C++.
NET2Java
[56]

helps
t
ranslat
e

.NET source code
to

Java
source code
;

i
t is
currently
available through a NetBeans plug
-
in
.


F
or mobile code,
t
his one to one source translation is not scalable
,

since
N

different languages would
require

N*N

translators

for cross
-
compiling
.

An
improved approach

could use
an intermediate language

and a virtual execution
system
,

such as Microsoft .NET
CLI
[48]
, and Java
[31]
.
Each

support
s

on
-
the
-
fly
compilation and dynamic
composition of application components.

Components written in
different languages are first compiled into t
he intermediate language and then deployed in
the virtual execution system. The resulting component written in different languages only
depends on this virtual execution system. Moreover,
N

languages
o
n
M

platforms

require

only
M
+
N

compilers to generate th
e final executables
,

instead of
M
*
N
.

Unfortunately,

a
virtual execution system introduces extra overhead compared
with one
-
to
-
one language transform
ation
.
Furthermore, i
n
legacy system
s
, it is not
usually
feasible to
utiliz
e

virtual execution systems
.
Sec
tion 3.1 includes more
discussion
on this topic
.






14

With the popularity of XML, t
here is a
n increased

momentum of activities related
to XML representation of source code.
Some

work
[87]

uses

the top
-
down approach
t
o
annotat
e

object
-
oriented languages, including C++ and Java
,

with XML tags
.
First
,
Document Type Definitions
(
DTDs
)
specif
y

the mappings from the Java and C++
grammar to the corresponding
Abstract Syntax Tree
(
AST
)
.
Then
, semantic actions
are

added
to the

parser
to annotate the input source code with XML tags. The C++ AST
XML
is

generated from

the

IBM VisualAge C++ Compiler.
Java Compiler Compiler
(JavaCC)

[30]

is used to generate t
he Java AST XML.

B
ased on
Inte
rMediate
Language

(IML
)

[64]
,

Resourc
e Graph (RG)
uses XML to
represent

the program

from a
global point of view
. B
ut
it is
not
designed
for fine
-
g
r
ained
representation
s

of source code.

BPEL

[5]

is a pure XML
-
based language that is used to compose multiple
Web
service
s

into an end
-
to
-
end business process. Clients submit a script written in BPEL to a
BPEL execution engine in which the script is interpreted and executed.

The execution
engine can publish the BPEL script as a
Web service
. BPEL is mainly used to
choreograph
Web service
s
. Thus,
it

is not designed
to be
a full
y

programming language
for mobile code. Another alternative
to
BPEL
,

called BPEL4Java

[5]

adds Java code
snippets into BPEL to complement BPEL script
s

for complicated choreograph
y of
services
.

The
GCC
-
XML

[16]

tool generates the XML representation of C++ code from the
internal GCC da
ta structure
s
. Compared with code written in C++, the generated XML
snippet is much easier to parse. Currently, GCC
-
XML only deals with the definition of
classes, functions, and structures. There is no XML output for function bodies.






15

Water
[82]

is a pure XML language designed for programmers to develop Web
services. It adopts the syntax defined in ConciseXML, an extension of XML 1.0. In
W
ater
, programmers use XPATH to manipulate XML data.
It has built
-
in data types,
such as Vec
tor and Hash Table. Programmers can also define their own OO data types.
As an interprete
d

language, Water programs run much slower than the same program
written in Java, C#, or C++.

As an alternative tree abstraction for program
s
,
CodeDom

[50]

is another
interesting technique specific
to the

.NET Framework
.
CodeDom stands for the Code
Document Object Model

and is based
on a

uniform

tree
model for rendering source code.
The tree model is
a language independent ob
ject model for representing the structure of
source code in memory
. It
allows pro
grams to be dynamically created

and

compiled at
runtime.

The target languages could be V
isual
B
asic
, C#, and in the
future
, any .N
ET
compatible lan
g
u
a
ges.


2.3.

Web

and
Grid

S
ervic
es

D
eployment

Typically, a

Web service

is a dynamic
ally
-
link
ed

library (DLL) that resides on a Web
server and whose methods can be called over the Internet. Categorized by the deployment
mechanism,
Web service
s

have two types: container
-
dependent or contai
ner
-
less
standalone
Web service
s
.
The container u
sually

provides
buil
t
-
in deployment, service
dispatching, thread
-
pool
s
, share
d

data, and service life
-
cycle management.

Service
programmers only focus on the application level logic.
C
ontainer
-
less standalon
e
Web
service
s
must

implement the

above mechanisms by themselves
. This is the case
, for
example,
with

plain gSOAP Web services.






16

Weissman et. al.
[26]

argue the need for dynamic
Grid

service hosting, where
Grid

s
ervices

can

move to
Grid

locations where they are required or perform better. They
build adaptation into

adaptive
Grid

service (AGS) classes, which effectively allow
services to change their

behavior based on the current conditions of the resources they
us
e.
The work described in this work

do
es

not tackle the problem

of deciding how and
when to adapt, instead concentrating on the mechanism. The AGS approach assumes a
homogeneous container

environment; in particular, the mechanism is built into the
Tomcat
We
b service
s

container, and

services are deployed using WAR files.
The

work

in
this thesis
will allow AGS classes

to run on top of multiple container types in t
he

same
Grid
,
t
hereby extending the applicability of
Weissman

s
work.

Watson et. al.
[60]

advocate the decoupling

of
Web service
s

providers from host
providers by

allowing dynamic
Web service

deployment

the

movement of services
from one hosting

environment to another. This
enables

traditional job scheduling
functionality, where

distributed systems can route jobs/services to

appropriate locations
to meet various scheduling

criteria.
Their approach, in the Dy
n
a
soar project,

layers
traditional job scheduling functionality on

top of
Web service
s
. The authors desc
ribe an

architecture and implementation that can run over

any service model that supports
dynamic service

deployment, but do not address the

implementation of any particular
such model.

Currently, different containers have different strategies for service
deployment.
The
f
ollowing
subsections describe
four different
containers
that

provide support for
dynamic
W
eb

and
Grid

service deployment and life cycle management.






17

2.
3
.1
Java
C
ontainers

In
Java,

the

J
2EE specification

[31]

describes the
details
that govern the d
evelop
ment of

Web services

on top of J2EE components. Several Java technologies
are used
together to
support
Web service
s
. The Java API for XML
-
based RPC (JAX
-
RPC)

[34]

provides
support for
Web service

calls using the SOAP/HTTP protocol. The SOAP with
Attachments API for Java (SAAJ)

[35]

provides support for manipulating low
-
level
SOAP messages. The Java API for XML R
egistries (JAXR)
[33]

provides client access to
XML registry servers.

The
Web service
s

for J2EE specification, a
lso called
Java WSDP

(Web Services
Developer Pack)
, provides support for multiple Web containers.
I
t can be
integrate
d

with
the following containers:

Sun Java System Application Server Platform Edition 8
,
Sun
Java System Web Server 6.1
,
and
Tomcat 5.0 for Java WSDP
.

The newest Sun App Server and
Apache
Tomcat
both
allow

new
W
eb
applications

to be instal
led while the container is running.
T
o deploy a
Web service

on a
remote machine dynamically,
developers need to package
the
Web service

implementation
code
, dependencies, and the
deployment

descriptor

into
a
W
eb
application

archive (WAR). The WAR file
comp
resses all

of this

directory
-
structured

content into one
Java archive file (JAR)
.

Usually,
a
Web service

WAR file

also includes
schema (WSDL
)

files, and the service deployment description (WSDD).

The

Sun App
Server and Apache Tomcat also

provide a GUI base
d
W
eb page to install, un
-
install, and
reload
the packaged W
eb application dynamically.

Web services could also be deployed by just copying the corresponding WAR file
into a specific directory designated by the hosting server. This directory is monitored
by a





18

watchdog daemon on the hosting server. Thus, any newly copied WAR file can be
detected by the daemon and then be deployed into the container by this daemon. This
approach is called XCOPY deployment.

2.3
.2
ASP
.NET
XML
Web
S
ervice
s

Using ASP.NET,
progra
mmers

can create, deploy, and access an XML
Web service

in
the IDE
Microsoft Visual Studio .NET.
In ASP.NET, a
Web service

is an ASP.NET
application
, which

is installed under a virtual directory on a Web server. It
includes the
compiled assembl
ies

that pro
vide functionalit
ies

for the application.

A .NET a
ssembl
y is the basic unit of
application

component in .NET. It

contain
s

four elements:

(
1
)

Microsoft Intermediate Language
(
MSIL
) Code: MSIL is the code that
the common language runtime can understand
, sim
ilar to Java byte
-
code.
(
2
)

Meta
-
data:
Contains information about the types, methods
,

and other elements defined in the code
.
(
3
)

Manifest: Contains name and version information, a list of included files in the assembly,
security information
,

and
more.
(
4
)

Supporting files and resources
.

An assembly is self
-
describing
,

and the .NET runtime can load or unload it on the fly,
thereby enabling

dynamic deployment in ASP.NET.

D
eploy
ing

the XML
Web service

requires

a Web server such as Microsoft
Windows 2000 Serv
er running
the Internet Information Service (
IIS
)
.
Developers

create

a
virtual root (also called a virtual directory) on the Web server
,

and copy
all the
supporting
files to the physical directory associated with that virtual directory
.
This is similar to
the
XCOPY approach
for

Java containers
.
By adding or removing the virtual directory in
the
IIS control panel, one can deploy or un
-
deploy the specific
Web service
s

without





19

affecting other
s
.

I
t is also possible to automate the deployment process by making u
se of

deployment projects


in VS .NET

or the install
-
shield installation tool.

2.3
.3
C/C++ Apache Axis

In C/C++ Apache Axis

[1]
,
code written in C

or
C++
can
be called as a
Web service

through either

Java Nati
ve Interface
(
JNI
)

[32]

or a native C/C++ SOAP environment.

In Apache Axis C/C++, a
Web service

is a standard .so file
. Upon receiving
SOAP messages, Axis
loads
the .so file dynamically to serve the requests.

T
o deploy the
library,
the programmer copies

the new .so file to
the
appropriate

directory

and then
modif
ies

the
Web
S
ervice

Deployment Definition

(WSDD
) file with the inf
ormation that
Axis needs to
deploy
the

Web service
.

The mod_gsoap
open source project
[52]

is
designed to deploy C++ modules generated by gSOAP into
the
Apache Axis Web server
.

2.3
.4
G
lobus

Grid

S
ervices

C
ontainer

The

Globus Toolkit

contains

two levels of deployment, container
-
level and service
-
level
.

In c
ontainer
-
level deployment
, deploying new services

requires restarting the entire
container
. Thus,
all services in the

container
must be

deactivated and re
-
activated.

S
ervice
-
level deployment

allows programmers to

deploy

or un
-
deploy a single

ser
vice

without shutting down the container
.

All other services are

unaffected.

The prerequisite
for
service
-
level deployment
is
that
the deploym
ent procedure
of one service will
not
impact requests to other services.

So far,
service
-
level

dynamic deployment
has not been
addressed in t
he GT3 and GT4 releases

[39]

.


Weissman et
.
al.
[26]

have
built

dynamic deployment in
to

GT
3

by using
the
Apache Tomcat server as the hosti
ng environment. With this approach,
developers
package their services
,

together
with the basic Java WS Core libraries
,

into
a WAR file





20

and deploy it
as a standard
Web application into Tomcat
.
Since Tomcat supports
dynamic
deployment
,

the
user can deploy
or

un
-
deploy GT3 Grid services dyn
amically.

An alternative approach
called
HAND

[39]

re
-
factor
s

the kernel structure of the
WSRF
-
enabled
GT4
Java WS Core standalone container

to support both container
-
level

and s
ervice
-
level deployment
. Compared with
Weissman’
s approach,

HAND represents

a
more lightweight dynamic deployment implementation
,

and simpler management.
In
this
approach,
services
are packed in
Grid

archive (GAR) format
; therefore

GT’s existing
deployment

mechanism

can be reused
. HAND in
cludes

three parts
: Deploy Approach
Manager,
Dynamic D
eployer
C
ore
, and
Service P
ackage
M
anager.

HAND uses
GSI
authentication and authorization
to make sure
only authorized clients can
deploy or un
-
deploy services
.

2.3
.5 D
e
ployment

Comparison

In conclusion, ASP.NET allows the administrator on the hosting server to use either
Visual Studio or XCOPY approaches to deploy an assembly, along with service
description files, as a
Web service
.
The assembly is compiled from any .NET
language
,

including

C#, VB,
Visual J++
, or
Visual C++
.

Apache Tomcat provides a Web page based GUI for

the

Tomcat administrator to
deploy a WAR file as a
Web service
. This WAR
file
includes everything Tomcat needs to
deploy the
Web service
, such as servic
e implementation

Java

classes, dependent
JAR

files, and service
description
files. Privileged users on the server can also accomplish the
deployment by copying the WAR file directly to a shortcut of the deployment directory.
Sun App Server provides
nearly

the same mechanism as Tomcat for deployment.






21

In GT3 and GT4

standalone container
s
, the GAR file is the deployment unit. Like
WAR, it includes all the implementation Java classes and service description files for a
Grid

service.

The command

globus
-
deploy
-
gar


is used to
deploy

a GAR file
and
the
command

globus
-
undeploy
-
gar


is used to un
-
deploy a deployed
Grid

service. The
deployment or un
-
deployment take
s

effect only after the container is restarted. As an
enhancement, users can use the approach describe
d in
[26]

or
[39]

to dynamically deploy
a GT4
Grid

service.

The

approach
described

in this
thesis

allows clients to deploy
X# mobile code
through the
installCode()

We
b service
. The X# mobile code
is
translated into
container specific languages on

the hosting server side and
incorporated into the mobile
code container. The target container could use Java, .NET
,

or C++
,

on
W
indows or Linux.

T
he
differences

between curre
nt
W
eb

and
Grid

service containers and
the

approach

described in this thesis
is
summarized in Table 1
.

Table
1
:

Deployment mechanisms in various Web and
Grid service containers


Privilege

Approach

Granularity

Languages

ASP .NET

Localhost admin

Visual Studio
and
XCOPY

Assembly

.NET

Tomcat

Container admin

WEB

and
XCOPY

WAR

Java

Sun App

Container admin

WEB

and
XCOPY

WAR

Java

GT3/4

C
ontainer admin

XCOPY

and

Service API

GAR, WAR

Java

This
Work

Container admin

Service API

M
obile code

.NET, JAVA
, and

C++






22

2.4.

Web

and
Grid

S
ervices

S
tate
M
anagement

For years, people have discussed the choice between stateful services and stateless
services in distributed systems.
It is easier to recover a stateless service
,

and a pool of
stateless service
s can serve client requests
with

better scalability. S
tateful services
support context
-
aware messages and
can

therefore
be
more efficient. Any non
-
trivial
service will include stateful i
nformation and state management.

T
he general arguments
are whether or
not the service consumer
must
assume the state for each request, and
whether or not
to support

a convention for clients to manipulate state.

P
lain
Web service
s

(as currently specified by the W3C) were designed to be
stateless
,

and to send responses only b
ack to the caller,

using a request
-
response pattern.
T
he WSRF specifications, introduced in January 2004 after
the
re
-
factoring of OGSI,
represent

a canonical means
with
in
the
Web services arch
itecture to manage state.

The following description of WSRF is

based very closely on
several specification
documents; namely

[70]
,

[40]
,

and
[72]
.

In WSRF, a WS
-
Resource is

a composi
tion of a
Web service

and a stateful
resource


[70]
.
There are four related specifications in WSRF
, namely, WS
-
ResourceProperties

[70]
, WS
-
ResourceLifetime

[40]
, WS
-
ServiceGroup

[72]
,

and

WS
-
BaseFaults
.

From
the
user

s point of view, WSRF simply defines
the conventions to
interact with stateful Web services
.
Clients reference the
WS
-
Resource by a WS
-
Addressing Endpoint Reference, and query or modify WS
-
Resources through Resource
Property documents.

Since these four WSRF specifications are compliant with the WS
-
Interoperability (WS
-
I) Basic Profile, any WS
-
I compliant
Web service

cl
ient can interact
with WSRF services.






23

The
WS
-
Resource

Properties
specification
defines how to query and modify the
XML documents
that

reflect the state of
each
WS
-
Resource.
By using Resource Property,
a
WSRF service programmer can hide the internal impleme
ntation details and data
representation of WS
-
Resource
s

from
the
end user. This is analog
ous to
data
encapsulation and hiding

in O
bject
O
riented

language
s
.


In WSRF,
R
esource
P
roperties are declared in
an
XML Schema,

and
a set of
standard
P
ort

Types
allow
s

user
s

to interact with a service's R
esource
P
ropertie
s. Each of
these four
P
ort

Types exposes a single operation, with the same name as the
P
ort

Type.
P
ort

Type GetResourceProperty

allows us
ers

to access the value of any resource property
given its QName.

This
P
ort

Type provides a general way of accessing R
esource
P
ropertie
s without the need of an individual

get


operation for each R
esource
P
roperty
.
The corresponding

setter


operations, such a
s Update, Insert, and Delete, are

defined in
Port Type
SetRes
ourceProperties
.
Port

Type
GetMultipleResourceProperties

provides the
access operation on multiple
resource properties

in one call.
Port Type
QueryResourceProperties allows us
ers

to

use XPath to
perform complex queries on the
R
esource
P
roperty
document.

Th
e WS
-
ResourceLifetime
specification defines
two means
of destroying

a

WS
-
Resource:
explicit
immediate destruction and
implicit lease
-
based

scheduled

destruction.

Immediate destruction
allows us
ers

to explicitly
destroy

a WS
-
Resource
.

Scheduled
destruction
allows us
ers

to specify
the lease time for using a particular WS
-
Resource.

T
he
lease

defines

the destruction time of a resource some time in the future
.
A c
lient
must
periodically renew the
lease;

otherwise

the resource will
be automaticall
y
reclaimed or
d
estroyed by the resource manager
. This
prevent
s

resource leakage in case the user does





24

not release the resource
explicitly
for some reason (network failure, programmer errors,
etc.).

The
WS
-
ResourceLifetime specification

defines a
standard WSRF
P
ort

Type
t
o
provide scheduled destruction
. This Port Type includes one
operation
called
SetTerminationTime
and
two resource properties

called
TerminationTime and
CurrentTime. TerminationTime
is the time
when the resource is set to be destroyed, and
the value of Curr
entTime
is
the time in the
hosting
machine.

Essentially, these two
resource properties are read
-
only.
The c
lient must use
the
SetTerminationTime

operation
to set the scheduled destruction time.

The WS
-
ServiceGroup
specification
specifies how
to
group serv
ices or WS
-
Resources together

to meet application or domain specific requirements
.

It defines
standard resource properties for users to query and retrieve the content of a service group
or the details of a member in the service group. Through the standard
operation, users can
add new members into the group.
The
basic

functionalities are
the bas
is

of more powerful
discovery services
,

which allow us
ers

to group different services together and
to
access
them through a single point of entry (the service group).

The
WS
-
BaseFaults specification defines a stand
ard format
f
or

reporting faults
when exceptions are thrown during a
Web service

invocation. It provides an XML
schema type for base faults, and describes the rules of how to use and extend the base
fault type
s in
Web service
s
.

The approach descr
ib
ed in this thesis uses
WSRF mechanism to manage the state
of mobile code

for WSRF
-
enabled Web or
Grid

service container
s

such as GT 4.0 and
WSRF.NET 3
.0
.

WS
-
C programs use

persistent


variables to access WS
-
resources
. For
non WSRF
-
enabled Web service container
s

such as
the
gSOAP based C++ container






25

implemented in this work
,
an approach
similar to
Microsoft AppDomain
s is adopted
to
maintain the state of mobile code.
T
he advantage

of
the approach described in this thesi
s
is that

the same stateful WS
-
C code can be installed in
to different containers and can run

there regardless

of

whether or not
it is WSRF
-
enabled.

2.5.

Web

and
Grid

S
ervices

I
nvocation

Web service
s

promise a standards
-
based platform for distributed computing
i
n a
heterogeneous

environment like

the

Internet.
There are two different approaches to
access
ing

a
Web service
.
The first

is
RPC
-
oriented
;

that is, a
Web service

call is treated
as

a remote procedure call.
In this case, the remote call is usually synchrono
us; that is, the
caller wait
s

for
a

response after sending the request.
A
client stub can be pre
-
generated
from WSDL and used at runtime.
A

dynamic proxy pattern could be applied to
wait to
choose the stub until runtime.
In the

other
messaging
-
oriented

app
roach
, a
Web service

call is executed by

sending and receiving messages in a standard format so that all
systems can understand them.
T
he se
nding and receiving could be
asynchronous
; that is,
the Web service client could send a one way message and then be
re
-
contacted

some time
later.
The message can be manually generated or mapped to
a

local in
-
memory
object and
manipulated
programmatically
.


M
any tools in different
platforms
can

generate service skeleton
s

and
client stub
s

from
a
WSDL

document that resides

either

in

a file or
at
a URL
.
For example, in
ASP.NET,
wsdl.exe
is
used to
generate
client stubs and
service skeletons

from WSDL
files, XSD schemas
,

and .discomap discovery documents.
In Visual
S
tudio IDE, t
his tool
is
used in conjunction with disco.exe

t
o generate the Web Reference

(the client stub)
.
The
target
language

could be C#,
V
isual
B
asic
, J
#
,
or

C++. In the Java community, for Axis





26

Java,
WSDL2Java

is used to generate client stubs, service skeletons, and data types in
Java
,

from WSDL. For JWSDP, th
e tool is
wscompile
, which

can also generate a
description file
to specify

the detailed mapping from WSDL documents to Java class
es
.
In gSOAP,
wsdl2h
first
generate
s

a header file with the
Web service

operations and the
C/C++ data types

from
WSDL
;

this hea
der file
is

input to t
he gSOAP soapcpp2 compiler
,
which

generates XML serializers for the data types (soapH.h and soapC.cpp), the client
-
side stubs (soapClient.cpp), and server
-
side skeletons (soapServer.cpp).


The
alternative stubs
-
less approaches are

dyn
amic invocation interface (DII)

and

SOAP messaging
.

In contrast to a static stub or dynamic proxy client, a DII client does
not require
statically
generated stub
classes.

Essentially, DII is
equivalent

to generat
ing

the SOAP XML message
or XML
DOM tree

on
the fly.
Thus, t
he source code for a DII
client is more complicated
.
In Java,
programmers can use
SAAJ (SOAP with Attachment

API for Java)
to create SOAP messages, and send it to Web service
s
.
In ASP.NET, WSE
(
Web S
ervice

Enhancement)
provides .NET languag
e binding classes for SOAP envelope,
SOAP body, SOAP header, SOAP element
,

etc. Programmer
s

can use th
e
se classes to
generate SOAP messages on the fly. In gSOAP, programmer
s

can use the DOM tree
parser

and APIs

for this purpose.

SOAP is the most widely u
sed binding for accessing Web services. However
,

other

bindi
n
gs or protocol
s

can also be used to access the same service. In
the
Web
S
ervice

Invocation Framework (WSIF)
[42]
, a

new binding can be plugged in
to

WS
IF
at
runtime

and Web services are invoked through
a simple API
in
a uniform way.


Similar to reflection in languages like Java and C#,
Web service
s

reflection
is
used in this work to
provide a uniform interface for clients to access the dynamically





27

loaded

mobile code.
The
basis

of Web reflection is xsd:anyType, which can be used to
represent any legal XML snippet. It is similar to the base class type for all other classes in
languages that support reflection, for example, class “System.Object” in C# and cl
ass
“Object” in Java.
A WSDL document can use xsd:anyType to define a static
interface
,
which can be used by

clients to access the dynamic mobile code on the hosting
Web
service
s

server

via a statically generated client stub
.
The
drawback of

this approach
is
that
it makes Web and Grid services more weakly typed by postponing the type check to
runtime. I
t
also
requires

the programmer to
explicitly check
and typecast
the parameters