Service organization and information consistency for service grid*
Hai Jin, Deqing Zou, Feng Mao, Zongfen Han, Xuping Tu
Huazhong University of Science and Technology, Wuhan, 430074, China
Email:
{hjin, deqingzou, fmao}@hust.edu.cn
Abstract. As the emergence of Open Grid Service Architecture (OGSA), service grid is seen as a
natural progression from computational grid. Because of the diversity and the complexity of the
applications, it is a large challenge for the research on service grid platform. Currently, the popular
information service systems are basically used to provide registry, publication, and management
for computing resources, data resources and network resources, and etc. However such systems
couldn’t meet the requirement of service grid. A perfect information service model, HowU
information service, is proposed for service management and organization. The “service” is
regarded as the basic unit of information publication, and a novel service naming and meta-data
description mechanism is provided in this model. A grid user is not concerned with the resource
details of a service, but its existence and current serving capability. In this paper, we focus on the
information consistency issue of HowU information service about how to guarantee service
existence in wide area and service information validity in organization area.
1. Introduction
Grid technologies [1][2] enable large-scale sharing of resources within all kinds of consortia of
individuals and/or institutions. In the grid system, information sources are necessarily distributed and
individual sources are subject to failure. One consequence of its distributed characterization is that we
cannot in general provide users with accurate information. The total of number of information
providers can be large, and both the types of information sources and the ways in which information is
used can be highly varied. In these environments, the discovery, characterization, and monitoring of
resources, and computations is a challenging issue. The grid information service need record the
identity and essential characteristics of services available to community members, and maintain service
validity. Notification framework is proposed as a basic means for determining the existence and
properties of an entity in wide area network. Each framework message is propagated with timestamps.
Based on soft-state model, a robust notification mechanism coupled with a graceful degradation of stale
information is provided. According to network performance and system load, Application selectable
time intervals determine the longevity of each datum within the system. Such intervals are specified in
message timestamps.
Inter-operation between different systems is also a challenging issue in grid platforms, and web
services technology is a popular solution at present. Web services[3] are Internet based applications that
communicate with other applications to offer service data or functional services automatically. These
services are implemented Internally by integrating other types of applications or by using the services
* This paper is supported by National Science Foundation of China under Grant No. 60125208 and
No. 60273076
provided by other web services, which may be internal or external. The development of web
technologies and standards such as HTTP, XML, SOAP, WSDL, and UDDI enables pervasive adoption
and deployment of web services. A service level agreement is an agreement regarding the guarantees of
a web service. That is, A service provider “contracts” with a client to provide some measurable
capability or to perform a task by s service[4]. Service Level Specifications (SLS) are used to describe
the appropriate QoS parameters that a SLA demands.
2. Related Works
Peer-to-peer[5] paradigm dictates a fully-distributed, cooperative network design, where nodes
collectively form a system without any supervision. Its advantages include robustness in failures,
extensive resource-sharing, self-organization, load balancing, data persistence, anonymity, etc. Current
search algorithms for unstructured P2P networks[6] can be categorized as either blind or informed. In a
blind search, nodes hold no information that relates to document locations, while in informed methods,
there exists a centralized or distributed directory service that assists in the search for the requested
objects. Informed method is more suitable for global information searching and performance prediction
than blind method.
The Globus[7] platform can be viewed as a representative peer-to-peer system. There doesn’t exist a
centralized supervision over all kinds of grid resources in Globus, and each task is submitted and
controlled by a grid resource. Globus adopts an informed method, The Monitoring and Discovery
Service (MDS2)[8], for source searching. MDS2 provides an effective managing strategy for both
static and dynamic information about the status of distributed components: networks, compute nodes,
storage systems, instruments, and so on. It adopts a hierarchical structure to collect and aggregate
service information. MDS2 is one of most popular grid information service systems at present, but, as
the information servers of a grid system (based on Globus) is constructed in tree architecture, and
passive pull mechanism is adopted between two information servers with registration relationship,
system load in high-level information servers will increase violently, and information consistency
couldn’t be guaranteed. Based on Virtual Organization (VO), the distributed architecture and soft-state
registration is proposed[9] to make the system highly fault tolerant, but it is difficult to achieve global
service information. Index service in Globus Toolkit 3 is developed oriented web services, but there
isn’t an effective name space to organize services in the whole grid, it only depends on domain name or
IP address to locate a service.
The Relational Grid Monitoring Architecture (R-GMA)[10][11] is developed based on the relational
data model and Java Servlet technologies. Its main use is the notification of events, that is, a user can
subscribe to a flow of data with specific properties directly from a data source. R-GMA consists of
three components Consumers, Producers, and a Registry. However, there exists a problem how to
organize registry component when distributed systems extends to a large scale. Hawkeye is a tool
developed by the Condor group[12][13], and its main use case is able to offer monitoring information
to anyone interested and to execute actions in response to conditions. The architecture of Hawkeye
comprises four major components: pool, Manager, Monitoring Agent, and Module. However, as
periodic pull mechanism is adopted for information interaction by Manager component, it will be
overloaded as hosts increase largely. That is, such system couldn’t extend to a large scale.
UDDI provides a standards-based set of specifications for service description and discovery, as well
as a set of Internet-based implementations, and a programming model and schema, which define the
rules for communicating with the registry. All APIs in the UDDI specification are defined in XML,
wrapped in a SOAP envelope, and sent over HTTP. At present, UDDI doesn’t provide an effective
mechanism to guarantee information validity.
Fully studied the above popular systems, we have proposed a perfect information service model,
HowU information service, for service management and organization. HowU information service is
designed based on the principle about how to guaranteed service existence in global area and service
information validity in organization area. The rest of the paper is organized as follows: Section 3, we
have proposed HowU information service framework, at the same time, a service naming and
organization mechanism, and the meta-data description about the serving capability of a service are
introduced. Section 4, we focus on the information consistency issue of HowU information service
about how to guarantee service existence in wide area and service information validity in organization
area. Finally we give the simulation and the performance analysis.
3. HowU information service framework
Fully studied the above popular information service system, HowU information service is designed
based on the following principles:

Resource monitoring in an organization
It is inadvisable for grid system to monitor resources in
grid area because of system scalability and organization security.

The “service” is as the unit of information publication
The service interface, serving capability
and related usage policy should be published. The resource details of a service should not be
exposed to the outside.

Service information validity within an organization
Services are managed and scheduled
uniformly within an organization based on the same security policy. Organization information
service need provide current serving capability of the services for service negotiation and
scheduling in the organization.

Service existence in global area
Grid information service should determine whether services in
any global information server exist at present.

Effective service naming and routing in global area
A reasonable service naming and routing
mechanism should be provided so that a user request can be handled conveniently.
The HowU information service framework is depicted in Figure 1. According to resource
management pattern in grid system
an organization is regarded as the integral unit to manage
resource and provide service, it is reasonable that the whole framework is divided into two parts: index
service architecture, and organization information service. The first part need provide global service
routing and determine whether the registered services exist or not. Global service routing aims to help
the user with QoS demands[14] to locate the required service conveniently, which is related to the
topology of the index service, service naming, service meta-data description, and etc. Index service
architecture is normally constructed hierarchically according to the region divided principle. Such
architecture should extend dynamically based on the scale of grid system, for example, only one index
server is required when grid system is on the initial stage, and as the quantitative scale of grid system is
enlarged, the index service architecture will be extended to include many index servers, even several
layers. Service naming adopts a Virtual Organization (VO) and Physical Organization (PO) combined
style. The VO part of service name is dynamic, which is used to represent current activity a service
takes part in, and the PO part is fixed, used to provide service location. Information service within an
organization involves three components: organization information server, monitor, and service provider.
Service meta-data published in an organization information server should provide such contents as
service interface, peak serving capability, current serving capability and usage policy, and that
published in an index server includes the contents in an organization information server except for
current serving capability. Different from service routing function provided by the index service, the
organization information server need provide information validity guarantee of the services within an
organization, which is used for service negotiation and scheduling[15]. The monitor is used to evaluate
current serving capability of a service and monitoring the service and its related resources. Fully
considering the situations about the scalability, load and node performance in an organization, the
monitor can be deployed flexibly onto three locations: the organization information server, service
node, and the third party within the organization.
Service routing
Index
server
Index
server
Index server
Organization
information server
Organization
information server
Monitor
Monitor
Node
1
Fig. 1.
Node
k
Monitor
Node m
Node
1
Node
n
The HowU information service framework
3.1 Service naming and organization
Globus Toolkit version 3 and version 4 are the representative service grid platforms currently.
However their information service component couldn’t provide a perfect global namespace to
effectively organize all the services in grid system, and a service is located by domain name or IP
address. It’s not an effective way to locate grid service just by domain name or IP address. Considering
the experience of Globus MDS and the properties of service grid, a XML schema about a hierarchical
naming mechanism is designed and used by HowU information service, as depicted in table 1. Service
name in grid system includes two parts: one is the static part; the other is the dynamic part. The static
part is used to determine the location of a service, and the dynamic part represents an activity a service
currently takes part in. The static part is obligatory, and the dynamic part is optional. A service just
represented by the static name, and several services represented by the same static name and the
dynamic name, which take part in different VO activity, are mapped to the same service. The static
name includes three parts: service name (HowU-Service-name), host name (HowU-Host-name),
organization name (HowU-Organization-name), and grid system symbol(O) , which only has constant
value “grid”. The dynamic name represents VO name(HowU-VO-name). Both service name and
organization name can be represented by ontology technology. Organization name is used to represent
the domain-specific characteristic of a service, and service name is used for virtual service
representation. Virtual service technology enables consistent service lookup in grid area, and helps the
user with QoS demands to locate the required service. Host name is represented by domain name or IP
address in order to locate a service.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="ServiceDesDef">
<xsd:sequence>
<xsd:element name="HowU-Service-name" type="xsd:string"/>
<xsd:element name="HowU-Host-name" type="xsd:string"/>
<xsd:element name="HowU-Organization-name"
type="xsd:string"/>
<xsd:element name="HowU-VO-name" type="xsd:string" minOccurs="0"/>
<xsd:element name="O"
type="xsd:string" fixed="grid"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="Service" type="ServiceDesDef"/>
</xsd:schema>
Table 1
A naming mechanism of HowU information service
A simple example for a service name is as follows:
1)
HowU-Service-name
=
science
computing/MPI,
HowU-Host-name
=CGCL.hust.edu.cn,
HowU-Organization-name = /china/education/HUST/CGCL, O= grid.
Each kind of service includes at least a service represented by the static name. Its service name is
science computing/MPI; host name is CGCL.hust.edu.cn, and organization name is CGCL.
2) HowU-Service-name = science computing/MPI, HowU-Host-name = CGCL.hust.edu.cn,
HowU-Organization-name = /china/education/HUST/CGCL, HowU-VO-name =TaskForZhang, O =
grid.
this service takes part in a VO named TaskForZhang. Service name should not include too many
information, and some details should be represented by service meta-data description. However it is
necessary to organize services effectively according to the domain-specific characteristic and the
virtual service mechanism. Correspondingly, Service lookup is described as follows:
Grid-find-service <an information server address> <-NameSpace [part of HowU-Service-name |
HowU-Host-name | part of HowU-Organization-name | HowU-VO-name… = XXX ]1..N>
[–ServiceElement [wsdl:<element name>]0..M]
A user can specify the parameter ‘-Namespace’ to query services in a field, a host or an organization.
Service element structure is regulated by XML schema to describe service meta-data. The parameter
‘–ServiceElement’ can be specified in the lookup command to find services with some characteristics
in the whole grid.
3.2 The service meta-data description
As the unit of information publication is “service” in HowU information service, the resource details
of a service should not be exposed to the outside with consideration to organization security. In brief, a
grid service is a WSDL-defined service that conforms to a set of conventions relating to its interface
definitions and behaviors. Besides a service‘s interfaces, a user is also concerned with its serving
capability, which is used to determine whether the service could meet the user’s QoS demands or not.
As interface definitions and behavior descriptions of a service are relatively mature, we focus on the
service meta-data description about the serving capability in this section, and discuss how to evaluate
the serving capability.
3.2.1
The serving capability description
When a user queries the serving capability of a service, normally he also wants to know the related
usage policies, such as service price policy, QoS guarantee policy, and etc. The description about the
serving capability and related usage policies is similar with a SLA, and it is a suitable method to
describe the serving capability via a SLA-alike specification. The specification related to the serving
capability description published by the service provider aims to provide information for service
negotiation with a client, not to provide a SLA, as depicted in Table 2. Many elements are defined in
the specification, such as service lifetime (ServiceLifetime), service price policy (PricePolicy),
violation management (CausingEvent, Action), serving capability (CapabilityParameter), and etc.
Element “CapabilityParameter” is used to describe a piece of serving capability of a service, such as
response time, throughput ratio, and etc. It includes three sub-elements: Total, Current, and ValidPeriod.
Sub-element “Total” is used to describe a piece of peak serving capability; Sub-element “Current” is
used to describe a piece of current serving capability; and Sub-element “ValidPeriod” is used to specify
valid period for a piece of current serving capability. The specification given in table 2 is published in
the organization information server, and that published in the index server doesn’t include the
description of current serving capability and valid period because the index server only need provide
service existence guarantee.
<ServiceCapability name = “v1”>
<Obligation>
<CausingEvent>DelayPerMinute
</CausingEvent>
<Action actionName=”notification”
xsi: type=”Notification”>
<NotificationType>Violation
</NotificationType>
</Action>
<Action actionName=”penalty”
xsi: type=”minus”>
<Operand>
<LongScalar>10</LongScalar>
</Operand>
</Action>
</Obligation>
<ServiceLifetime>
<Start>
2004-3-2T12:00:00.000-04:00
</Start>
<End>2004-9-2T12:00:00.000-04:00</End>
</ServiceLifetime>
<PricePolicy>
<PriceUnit>$</PriceUnit>
<PricePerMinute>
<LongScalar>10</LongScalar>
</PricePerMinute>
</PricePolicy>
<CapabilityParameter
name=” ResponseTime” valueType=”float”
unit=”transactions/second”>
<Total name="PeakResponseTime">
<value>
<FloatScalar>6.5</FloatScalar>
</value>
</Total>
<Current name="CurrentResponseTime">
<Value>
<FloatScalar>3.5</FloatScalar>
</Value>
</Current>
<ValidPeriod>
<Ruler xsi:type="Less">
<Operand>CurrentResponseTime</Operand>
<Operand>
<FloatScalar>5.0</FloatScalar>
</Operand>
</Ruler>
</ValidPeriod>
</CapabilityParameter>
<!-- other service capability -->
</ServiceCapability>
Table 2.
The service meta-data specification related to the serving capability description
3.2.2
The serving capability evaluation
A user is concerned with service existence and current serving capability of a service, and don’t care
for its resource details. Furthermore, the resource details of a service shouldn’t be exposed to the
outside. We need to solve the problem about how to evaluate current serving capability of a service.
Various service types have their special resource requirements. For a mere computing service, its
serving capability is mainly influenced by node CPU and memory. For other more complicated services,
their serving capabilities are influenced not only by node CPU and memory, but also by service
properties, the request number, and etc. For some services, we can measure current serving capability
directly, and for the other services, we need evaluate the serving capability by service influence factors.
Based on the linear interpolation formula, we propose a simple and effective method to describe the
serving capability evaluation. We take data intensive computing service as an example in the following.
At first we make the following definitions:

P  CPU idle , MEM idle , DISK idle  . It denotes available node resource, including available
CPU, available memory, and available disk. P(t) denotes available node resource changing over
time t.

N denotes available network bandwidth in edge router, and N(t) denotes available network
bandwidth changing over time t.

F denotes a piece of serving capability of a service, and F(t) denotes serving capability changing
over time t.

P(0), N(0), and F(0) represent current values.

F  F ( P, N ) ; F (t )  F ( P(t ), N (t )) .
If memory and disk space are large enough, F is related to CPU and network bandwidth. We use
F1(CPU, N ) to denote F. If network bandwidth equals to constant n, we have:
F1(CPU , n)  {F ( P, N ) | N  n, MEM idle  MEM enough , DISK idle  DISK enough }
The evaluation formula of this service is described as follows:
{F1(CPU , N i ) | 0  i  I , N i 1  N i  MaxBand / I , N 0  0, N I  MaxBand} (1)
Available network bandwidth is divided into I areas averagely, and CPU capability is divided into K
areas averagely. By adjusting available network bandwidth to a value Ni( 0  i
 I ) for the service in
edge router, we can measure serving capability changing over available CPU and get a group of serving
capability values as follows:
F1(CPU i , N i ) ( 0  i  K , CPU i 1  CPU i  MaxCPU / K , CPU 0  0, CPU K  MaxCPU )
According to the linear interpolation formula, we have:
F1(CPU , N i ) 
CPU  CPU i 1
CPU  CPU i
F1(CPU i , N i ) 
F1(CPU i 1 , N i )
CPU i  CPU i 1
CPU i 1  CPU i
0  i  K  1, CPU i  CPU  CPU i 1
By adjusting available network bandwidth to all the other values, we can get formula (1).
Based on formula (1), current available CPU and network bandwidth, we can get current serving
capability of the service:
F1( P(0), N (0)) 
N (0)  N i 1
N (0)  N i
F1( P(0), N i ) 
F1( P(0), N i 1 )
N i  N i 1
N i 1  N i
The evaluation formula is concluded before the service is provided to the outside. The monitor in an
organization evaluates current serving capability of a service based on the evaluation formula. The
evaluation formula for different service could be concluded by different method because of various
influence factors and changing rates. The above method only gives an example, which is fit for an
atomic service, and only related to two influence factors. For a complex service, the serving
capabilities of its atomic services should be evaluated separately at first, and then be integrated into a
whole with the consideration of service composed cost.
Some services may be related to one or more
influence factors, and their serving capability evaluation formula can also be concluded based on the
linear interpolation formula. The formula for one influence factor only includes a function, not a group
of functions for two influence factors. The formula for more than two influence factors can be
represented by multi-dimension function group. In additional, there is a special service type with
different serving capability changing rates within different scope of influence factors, for example, the
response time of database access service changes very slowly when the concurrent number of the user
request is less than a threshold value, otherwise the response time increases rapidly. For this service
type, the threshold value is taken as a critical point for the serving capability evaluation.
4. HowU information consistency mechanism
4.1 Service state description
Compared with Open Grid Service Infrastructure (OGSI), the WS-Resource Framework (WSRF) has
proposed such a principle that a service is stateless, and a resource changes over time frequently. It is
necessary to consider information validity of the resources and services in the local level. If we want to
keep information validity in global area, it will increase communication load in grid system largely, and
it is difficult to maintain information consistency between the information servers in global area and
the service provider.
However, from the perspective of the service consumer, he need negotiate his
QoS demands on a service with an organization, so it is enough to guarantee information validity in the
organization information server. In the index service level, it is enough to guarantee the existence of the
registered services.
4.1.1
Service states in the index server
For a service in an index server, there exist four states. The meaning associated with each state is
described below:
S0: it represents the initial state when the service is registered to the index server successfully;
S1: The service is usable;
S2: The service is unusable temporarily, or whether it is usable or not couldn’t be guaranteed;
S3: The service is destroyed.
There are two important timestamp values, labeled TS1, TS2, for the service in the index server. The
values of the two timestamps are related via the constraint: TS1 <= TS2. TS1 is used to determine
whether the service is usable, and TS2 is used to determine what time to destroy the service. Service
lifetime is given in the service description document when the service is registered to the index server,
and TS2 is set to the lifetime. Notification message, received by the index server, normally need carry
the timestamp. A suitable representation of global time, which is convenient to locale-specific
synchronization to the global time, is adopted to express the timestamp. Notification message includes
two timestamp values labeled MS-TS1, MS-TS2. The values of the two timestamps are related via the
constraint: MS-TS1 <= MS-TS2. The message sender asserts the service exists at time MS-TS1, and is
expected to exist until at least time MS-TS2. Time MS-TS1 is used to determine whether the received
message is the latest one. If the received message is the latest one, TS2 is set to MS-TS2, and otherwise
the message is ignored. Assume the index server admits a service fails for a period of time, labeled T,
before the service is destroyed, and Current_TS denotes the current time. The service’s state is
determined based on the following principle:

A service is registered successfully, and no notification message is received by the index server,

the service’s state equals to S0;
If TS1  Current _ TS , the service’s state equals to S1;
If TS1  Current _ TS  TS 2 and the service failure period  T, the service’s state equals to S2;
If TS 2  Current _ TS or the service failure period > T, the service’s state equals to S3.


4.1.2
Service states in the organization information server
For a service in the organization information server, there exist five states. The meaning associated
with each state is described below:
S0: it represents the initial state when the service is registered to the organization information server
successfully;
S1: information about current serving capability of the service is valid;
S2: The service is usable, but information validity about current serving capability couldn’t be
guaranteed;
S3: the service is unusable temporarily, or whether it is usable or not couldn’t be guaranteed;
S4: The service is destroyed.
Compared with services states in the index server, there are three important timestamp values,
labeled TS1, TS2, and TS3, for the service in the organization information server. The values of the
three timestamps are related via the constraint: TS1 <= TS2 <= TS3. TS1 is used for determining
whether current serving capability of the service is valid, TS2 for determining whether the service is
usable, and TS3 for determining what time to destroy the service. Different from the index service, TS3
is set to the lifetime. Notification message, received by the organization information server, includes
three timestamp values labeled MS-TS1, MS-TS2, and MS-TS3. The values of the three timestamps
are related via the constraint: MS-TS1 <= MS-TS2 <=MS-TS3. The message sender asserts current
serving capability value of the service is valid at time MS-TS1, and is expected to be valid until at least
time MS-TS2.The service is expected to exist until at least time MS-TS3. Time MS-TS1 is used to
determine whether the received message is the latest one. If the received message is the latest one, TS2
is set to MS-TS2, and TS3 is set to MS-TS3, otherwise the message is ignored. The service’s state is
determined based on the following principle:

A service is registered successfully, and no notification message is received by the organization

information server, the service’s state equals to S0;
If TS1  Current _ TS , the service’s state equals to S1;

If TS1  Current _ TS  TS 2 , the service’s state equals to S2;

If

S3;
If TS3  Current _ TS or the service failure period > T, the service’s state equals to S4.
TS2  Current _ TS  TS3 and the service failure period
 T, the service’s state equals to
4.2 Information service interaction mechanism
For HowU information service, there are key issues about how to guarantee service existence in
global area and service information validity in organization area. In this section, we will discuss the
suitable interaction mechanism adopted by HowU information service. In order to be consistent with
HowU information service framework, two-level interaction mechanism is introduced: the high level is
about outer organizational interaction, and the low level is about inner organizational interaction.
4.2.1
Outer organizational interaction
Outer organization interaction is used for the interaction between an index server and its closest
low-level information servers, which register the services to the index server. Currently, popular
wide-area interaction mechanisms include passive pull and push. Passive pull is used widely, such as
Globus MDS, Google searching, and etc. coupled with passive pull, information cache is adopted for
each piece of information and valid period is set. Query information comes from the cache of the
information server when current time doesn’t exceed its valid period limit, otherwise it will be retrieved
temporarily from the information providers or the low-level information servers. This mechanism is
proven to be a good method for information searching. However, for HowU information service, it’s
more important to determine whether or not the registered services exist in the index servers. Periodic
push is suitable for service lifetime management requirement. Another push mechanism, adaptive push,
is available for the user to subscribe the interesting events. When such events happen, the user will get
the notification. This mechanism isn’t suitable for service lifetime management requirement. For
HowU outer organizational information service, periodic push is used between two information servers
with registration relationship, as depicted in Figure 2. The timestamp value MS-TS2 in the messages is
relative to the notification interval and network delay.
Index server
Periodic push
Periodic push
Index server
Index server
Periodic push
Organization
information server
Periodic push
Organization
information server
Monitor
Periodic push
Adaptive
push
Monitor
Periodic push or
Adaptive pull
Service
provider 1
Service
provider N
Monitor
Service
provider 1
Periodic push or
Adaptive pull
Service
provider 1
Service
provider K
Fig.2. HowU information service interaction mechanism
4.2.2
Inner organizational interaction
The monitor is responsible for detecting resource and service status and evaluating current serving
capability of a service, and at the same time, it should inform the organization information server of
service information in time. There are tremendous differences among various organizations, such as the
performance of servers and service nodes, their scales, and etc. According to the organization actuality,
the monitor can be deployed onto three locations: the organization information server, the service
provider, and the third party.
 Situation 1: The monitor is deployed onto the organization information server
If the organization information server can provide high performance computing, or the organization
scale is relatively small, it is applicable to deploy the monitor onto the organization information server.
As depicted in Figure 2, two interaction mechanisms, including periodic push and adaptive pull, are
suitable for the interaction between the monitor and the service provider. If network communication
within the organization wouldn’t become a bottleneck, periodic push is applicable and can provide
information accuracy guarantee. Furthermore, it can save more network bandwidth than periodic pull.
Compared with periodic push, adaptive pull can save more network bandwidth at the cost of
information accuracy. Adaptive pull need spend some CPU cycles and memory spaces in the
organization information server. For periodic push, the interval value between MS-TS1 and MS-TS2 in
a piece of message can be set to the notification period, and the interval value between MS-TS2 and
MS-TS3 is relative to the message transmission delay and the message loss rate. For adaptive pull, the
interval value between TS1 and TS2 is achieved by prediction function, which predicts the next service
update, and the interval value between TS2 and TS3 is relative to the message transfer delay and
resource collecting spending.
 Situation 2: The monitor is deployed onto the third party
In order to lighten the load on the organization information server and the service providers, it is a
suitable way to deploy the monitor onto the third party. As depicted in Figure 2, periodic push or
adaptive pull is adopted for the interaction between the monitor and the service providers, just like
situation 1. The monitor adopts periodic push to inform the organization information server of the
existence and current serving capability of the monitored services. The timestamp intervals are set the
same as situation 1.
 Situation 3: The monitor is deployed onto the service provider
As depicted in Figure 2, the monitor can also be deployed onto the service provider. The monitor
need detect local resources and services periodically, and evaluate current serving capability of the
local services. Adaptive push is adopted for the interaction between the monitor and the organization
information server. When current serving capability of some local service changes, the monitor will
notify the organization information server in time.
We still take the service described in section 3.2.2
as an example to discuss the notification time. Based on the evaluation formula of the service, we can
get the notification time based on the following rules:
| F1 ( P(0), N (0))  F1 ( P(t past ), N (t past )) | BasicValue (I)
F1 ( P(0), N (0))  [threshold i , threshold i 1 ]
(II)

F1 ( P(t past ), N (t past )  [threshold i , threshold i 1 ]
tpast denotes the last notification time. If condition (I) or (II) comes into existence, the monitor will
inform the organization information server of current serving capability, F1( P(0), N (0)) , of the
service. BasicValue denotes the threshold value of the capability change scope. As a service can
provide various serving capability grades to the outside, [threshold i , threshold i 1 ] is used to denote
the value space of some serving capability grade. The monitor determines the interval value between
MS-TS1 and MS-TS2 according to the changing rate of the service, and the interval value between
MS-TS2 and MS-TS3 according to network status between the service provider and the organization
information server.
5. Performance analyses
Based on the campus grid of Huazhong University of Science and Technoloty, the experiments were
run on two sites:
a testbed at Cluster and Grid Computing Lab(CGCL) as an organization, and a
testbed at National Hydro Electric Energy Simulation Laboratory (NHEESL) as an index server. The
testbed at CGCL includes five Linux machines, one for the organization information server, one for the
monitor, and three for the service nodes with hostname CGCL_node1, CGCL_node2, and
CGCL_node3. Each machine is equipped with Xeon 1GHz, 40GB HD, 512MB Memory.
The testbed
at NHEESL with one machine is equipped with alpha 500MHz, 376MB Memory, 20GB HD.
Computing load（Gflops per hour）
Organization
communication
Information
Organization
load
consistency
information
(per second)
Periodic push
（situation 1）
Adaptive pull
(situation 1)
server
The
monitor
(360.0,360.0,
822.4
75B
73.28%
571.5
333B
92.38%
36.0
822.4
130B
71.23%
36.0
571.5
36B
94.69%
14.3
(772.0, 537.1, 485.2)
360.0)
(82.4,35.4,
25.0)
Periodic push+
(situation 2)
Adaptive push
(situation 3)
CGCL_node3)
94.69%
(situation 2)
Adaptive pull
CGCL_node2,
276B
Periodic push+
Periodic push
(CGCL_node1,
(360.0,360.0,
360.0)
(82.4,35.4,
25.0)
Table 3. The load and information consistence for organization information service
We assume a Poisson process for resource update and assume average update rate λ for three
different services (assume each service node provides a service) equals to 1/5, 1/10, 1/15 separately.
We also assume each resource collecting spends 0.1 GFlops; each current serving capability evaluation
spends 0.5GFlops; the process about receiving a piece of message and determining whether or not it
includes update spends 0.01Gflops. For simplicity, we assume service update rate is the same as
resource update rate. The interval for periodic push and periodic pull is one time per second. Adaptive
pull takes moving average mechanism as an example. Moving average mechanism is a very effective
and simple update prediction method, and a window should be maintained over the past update
timestamps. The moving average estimator does an average of the time interval between two
consecutive updates. We assume resource status description for a service node needs 50 bytes, and
current serving capability description needs 40 bytes. Push adopts the UDP protocol, and pull also
adopts the UDP protocol including two UDP transmissions.
The load and information consistence for Organization information service are depicted in Table 3,
and information interactions within an organization are only relative to three services. We can know
from Table 3, compared with other interaction mechanisms, adaptive pull in situation 1 requires
relatively less communication load and computing load at the cost of service information accuracy. If a
service’s update rate is well-regulated, a perfect prediction algorithm will improve information
accuracy. For situation 2 that the monitor deployed onto the third party, the difference between periodic
push and adaptive pull is just like that between two interaction mechanisms in situation 1. Adaptive
push in situation 3 has some advantages in such aspects as organization communication load,
information accuracy, and computing load in the organization information server, and there also exists a
disadvantage that it increases computing load of the service nodes apparently. When we construct
organization information service, a suitable interaction mechanism needs to be chosen according to the
actuality.
Fig.3. Delay law between the index server and the organization information server
The delay law between the index server and the organization information server is depicted in Figure
3. We can know that delay time distribution between two servers basically belongs to two groups: one
around 15ms or 16ms, the other around 7ms or 8ms. Only few number of delay time is out of the two
groups. The above outcome is produced by different routings. The received notification interval law in
the index server is depicted in Figure 4. The sent notification period is 500ms. Except for few interval
values, a majority of interval values belong to three groups. It is very important to determine the
notification period between two information servers and the interval between timestamp TS2 and TS1.
Service existence in an index server should be consistent with that in its low-level information server.
The notification period should be set according to network status. If available network bandwidth is
enough, the period can be set to a small value, and information accuracy can be guaranteed, otherwise
the period should be set to a relatively big value. Besides the notification period, the interval between
timestamp TS2 and TS1 is related to network delay. As depicted in Figure 4, the interval between
timestamp TS2 and TS1 can be set to 520ms.
Fig.4.
The received notification interval law in the index server
6. Conclusions and Future Works
Fully studied popular information services, HowU information service is proposed in this paper. The
whole framework is divided into two parts: index service architecture, and organization information
service. The first part provides global service routing and determines whether the registered services
exist or not. The second part is responsible for monitoring resources and services in an organization,
and provides information validity guarantee, which is available to service negotiation and scheduling.
We have discussed service naming and organization, and the meta-data description about the serving
capability of a service. We have also discussed service states in both the index server and the
organization information server, and interaction mechanisms in HowU information service. Finally we
have analyzed the load and information consistence issues in this framework. In the future, we will pay
more attention to service organization and routing, and investigate the efficiency issues of service
lookup and service scheduling based on HowU information service. The serving capability evaluation
of a service is also another important work for our future research because of the diversity of all kinds
of services.
References
[1]
I. Foster, C. Kesselman and S. Tuecke, “The Anatomy of the Grid”, Intl. Journal of Supercomputer
Applications, 2001.
[2]
W. E. Johnston, D. Gannon, and B. Nitzberg, “Grids as Production Computing Environments: The
Engineering Aspects of NASA's Information Power Grid”, Proceedings of 8th IEEE Symposium on High
Performance Distributed Computing, 1999.
[3]
The Web Services Industry Portal, http://www.webservices.org/.
[4]
H. Ludwig, A. Keller, A. Dan, R. King, “A Service Level Agreement Language for Dynamic Electronic
Services”, Proceedings of the 4th IEEE Int’l Workshop on Advanced Issues of E-Commerce and Web-Based
Information Systems (WECWIS 2002), IEEE, 2002.
[5]
R. Schollmeier, “A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer
Architectures and Applications”, Proceedings of the First International Conference on Peer-to-Peer
Computing (P2P’01), IEEE, 2002, PP101-102.
[6]
M. Kelaskar, V. Matossian, P.Mehra, D. Paul and M. Prashar, “A Study of Discovery Mechanisms for
Peer-to-Peer Applications”, Proceedings of the 2nd IEEE/ACM International Symposium on Cluster
Computing and the Grid (CCGrid’02), PP414-415.
[7]
I. Foster and C. Kesselman, “Globus: A Metacomputing Infrastructure Toolkit”, International Journal of
Supercomputer Applications, Vol.11, No.2, pp.115-128, 1997.
[8]
G. Aloisio, M. Cafaro, I. Epicoco, and S. Fiore, “Analysis of the Globus Toolkit Grid Information Service”,
Technical
report
GridLab-10-D.1-0001-GIS_Analysis,
GridLab
project,
http://www.gridlab.org/Resources/Deliverables/D10.1.pdf.
[9]
K. Czajkowski, S. Fitzgerald, I. Foster, and C. Kesselman, “Grid Information Services for Distributed
Resource Sharing”, Proceedings of 10th IEEE International Symposium on High-Performance Distributed
Computing (HPDC-10), 2001.
[10] S. Fisher, “Relational Model for Information and Monitoring”. Technical Report GWD-Perf-7-1, GGF,
2001.
[11] “DataGrid Information and Monitoring Services Architecture: Design, Requirements and Evaluation
Criteria”, Technical Report, DataGrid, 2002.
[12] M. Litzkow, M. Livny, and M. Mutka, “Condor – A Hunter of Idle Workstations”. In Proceedings of the 8th
International Conference of Distributed Computing Systems, pages 104–111, June 1988.
[13] Xuehai Zhang, L. Freschl, and M. Schopf, “A Performance Study of Monitoring and Information Services
for Distributed Systems”,
Proceedings of the 12th IEEE International Symposium on High Performance
Distributed Computing (HPDC’03), 2003.
[14] J. Al-Ali, F. Rana, W. Walker, S. Jha and S. Sohail, “G-QoSM: Grid Service Discovery Using QoS
Properties”, Computing and Informatics Journal, Special Issue on Grid Computing, Institute of Informatics,
Slovak Academy of Sciences, Slovakia, 2002, 21(4), pp363-382.
[15] C. Li, G. Peng, K. Gopalan, T. Chiueh, “Performance Guarantees for Cluster-Based Internet Services”,
Proceedings of the 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid
(CCGRID.03), IEEE, 2003.