The Florida State University
College of Arts and Sciences
Peer-to-Peer Computing with the
Simple Object Access Protocol
By Yunwei Wang
December 2001
A project submitted to the Department of Computer Science
In partial fulfillment of requirements for the
Degree of Master of Science
Major Professor: Dr. Robert van Engelen
1
Table of Contents
1.
2.
Project Goals and Accomplishments ................................................................................. 5
Introduction ......................................................................................................................... 6
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
3.
Design of the P2P Computing Infrastructure with SOAP ............................................ 16
3.1.
4.
Application Feature ..................................................................................................................................... 20
Implementation of the P2P Infrastructure with SOAP ................................................. 21
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
5.
The gSOAP Stub and Skeleton Compiler for C and C++ ............................................................................ 21
gSOAP Example .......................................................................................................................................... 21
Types and Data Structures used by the P2P Agents .................................................................................... 22
Client ........................................................................................................................................................... 24
Client Agent ................................................................................................................................................. 25
Service Agent............................................................................................................................................... 30
Service Provider........................................................................................................................................... 33
Statistics Provider ........................................................................................................................................ 34
Results ................................................................................................................................ 36
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
6.
7.
Web Services .................................................................................................................................................6
B2B (Business-to-Business) ..........................................................................................................................7
SOAP (Simple Object Access Protocol) ........................................................................................................8
WSDL (Web Service Description Language) [5][11] .......................................................................................9
UDDI (Universal Description, Discovery, and Integration) [6] .................................................................... 10
P2P (Peer-to-Peer) ....................................................................................................................................... 11
Industry Support for Web Service and P2P ................................................................................................. 14
Parts of the Code of smagicclient.cpp.......................................................................................................... 36
The Result of Service Agent: ....................................................................................................................... 36
The Result from Service Provider: .............................................................................................................. 37
The Result of Statistic Provider: .................................................................................................................. 38
The Result of Client Agent: ......................................................................................................................... 38
The Result of smagicclient: ......................................................................................................................... 40
Summary ............................................................................................................................ 41
Bibliography ...................................................................................................................... 42
2
Acknowledgments
Many have helped me to bring this Master Project to completion. My major professor, Dr.
Robert van Engelen, gave me help from introducing the P2P Computing Module to revising this
final version of project report. I can say, without his help, the project will not be so beautiful like
this.
I want to appreciate the help from the committee members: Dr. Ernest McDuffie and Dr. David
Whalley. Their knowledge and kindness help me to finish the project.
I also want to thank the entire faculties and staffs of Computer Science Department. They gave
me the knowledge of Computer Science during my two years of study.
3
Abstract
Peer-to-peer computing technologies aim to share computation resources and information
through a direct exchange of messages between remote systems. Napster and Gnutella are
popular peer-to-peer computing infrastructures that specialize in exchanging multi-media content
over the Web such as digitized music. However, the application of peer-to-peer computing is
much broader and new technologies and infrastructures have been proposed and are being build
to support remote computing and message exchange between disparate organizations and
businesses on the Web. This project investigates and implements a peer-to-peer computing
infrastructure using the Simple Object Access Protocol (SOAP). The infrastructure does not
adopt a centralized server for lookup and discovery of peers (i.e. no single point of failure), but
utilizes agents that dynamically propagate registry information over the network to agents on
other hosts for decentralized discovery and lookup of Web Services.
4
1. Project Goals and Accomplishments
The aim of this project is to design a Peer-to-Peer (P2P) computing infrastructure based on the
Simple Object Access Protocol (SOAP). SOAP is a language- and platform-neutral remote
method invocation and message exchange format. SOAP is a lightweight protocol and is based
on two existing Internet technologies: XML and HTTP. The project adopts a decentralized
approach to P2P and utilizes agents to provide registry, discovery, and lookup for locating peers
and services that are possibly replicated among several systems to improve quality of service of a
peer-to-peer infrastructure on the ever changing Web. Registry information is dynamically
propagated over the network and locally cached by agents for efficient access by local peers and
clients. Peers or clients connect to peers and services by accessing the cached registry of the
local agent to locate peer or service communication endpoint information.
The project involves three application implementation parts:

Design of a Client Agent application. An Agent serves requests made by Peer/Client
programs for lookup information on a particular Peer/Service and returns the
communication endpoint of the Peer/Service. In case Peers/Services are replicated (e.g. to
provide multiple access points), a communication endpoint is returned for an available
Peer/Service. A Client Agent caches registry information by periodically requesting
Service registry information from a list of designated Service Agents.

Design of a Service Agent application. The Service Agents together maintain a dynamic
Discovery system about services. It provides up-to-date information about services to the
Client Agents and in turn to the Clients.

Design a Client-Server programs to perform remote matrix calculations. The services are
added to the Discovery system and Clients request the service communication endpoints
from the local Client Agent.
The compilers and products used in this project include: C++ under Unix / Linux / Solaris and
VC++ for Win32; Java; gSOAP[13], Web Services, SOAP, WSDL, and UDDI
5
2. Introduction
This section introduces Web Services, SOAP, WSDL, UDDI, B2B, and P2P computing.
2.1.
Web Services
Web Service technology is a “behind-the-scenes” revolution in the Internet community. Just like
Web browsers have opened up the world to convenient document exchange over the Internet,
Web Services will open the Internet by providing remote computing services and dynamic
information exchange without the need for browsers (hence the “behind-the-scenes” limited
visibility to the public). Web Service technology provides a solution for problems that have
hampered effective language- and platform-neutral Internet-based computing infrastructures for
some time, such as the blocking of ports by firewalls and the adoptation of applications to
language-specific implementations (e.g. Java RMI). Web Services utilize SOAP as an XMLbased remote method invocation protocol, and exploit WSDL (Web Service Description
Language) and UDDI (Universal Description, Discovery, and Integration) for service
descriptions, service registry, discovery, and lookup.
Here is an example of Web Services. In an office network there are a number of printers that
provide print services. Suppose a user brings a notebook into the office and need to print a
document. The user connects the notebook to the network, starts the word document processor
and clicks the Print button. The word processor sends the print request to an agent program on
the notebook. The agent searches the network or the Web Service Discovery server running on
the network to locate a printer nearby that is available at that time. The word processor receives
the search result from the agent and communicates with the printer to setup the interface and
output the document. The user doesn’t need to know how to connect the printer. All the work is
done by Web Services that utilize remote method invocation to exchange printer information,
possibly by light-weight Web Services running in the printer hardware.
6
Here is another example of Web Services. Suppose you need to make an appointment to see a
doctor. To do this, you can go to the doctor’s website using your cell phone, PDA, or PC, and
request an appointment. The doctor’s appointment system will check your system’s calendar and
the doctor’s schedule to find a time available for both you and the doctor. The system assigns the
appointment to your calendar and the doctor’s schedule. On that day, your personel system, such
as the PDA, prompts you of the appointment. And at the same time, the doctor’s system requires
your medical history from the system’s database and your insurance information from the
insurance company’s system. Everything is ready when you walk in the doctor’s office. No need
to call, no need to wait. Everything goes automatically through the integration of Web Services
that utilize remote method invocation to exchange structured data.
2.2.
B2B (Business-to-Business)
B2B integration technologies connect disparate companies and business systems together. The
aim is to save cost by sharing customer information between the companies. An example is the
Dollar Rent A Car system that is integrated with the Southwest Airline system. This lets travelers
to book cars after purchasing airline tickets.
[1]
B2B requires single sign-in and log-on to access
multiple e-commerce sites. So a customer doesn’t need to repeatedly input personal information
when accessing different e-commerce sites. The customer doesn’t even need to know where to
find the item he or she wants. The integration allows customers to choose items on different sites
and pay the balances on different sites, all accessing the customer’s records through the B2B
integration framework. An example is Microsoft Passport. [2]
B2B has both benefits for businesses, service providers, and customers. Web Service
technologies makes services available to anyone who needs them on the Web. This allows
businesses to reduce operational costs and the complexity of maintaining an isolated system. For
customers, Web Services make relationships to Web sites more simple and dynamic. Customers
don’t need to waste time and energy to search and login to different Web sites.
7
2.3.
SOAP (Simple Object Access Protocol)
SOAP
[4][11]
is the heart of Web Service. Web Services utilize SOAP as an XML-based remote
method invocation protocol. SOAP is a language- and platform-neutral remote method
invocation protocol that adopts XML as the marshalling format and HTTP as the firewallfriendly transport layer. SOAP does not itself define any application semantics such as a
programming model or implementation specific semantics, rather it defines a simple mechanism
for expressing application semantics by providing a modular packaging model and encoding
mechanisms for encoding application defined data.
SOAP enables various devices, including PCs, PDAs, and servers, to exchange structured data
across the Internet – regardless of the operating system, programming language, development
environment, and hardware used.
The SOAP protocol consists of four parts:

The SOAP envelope construct defines an overall package with a header part and a body
part. The header part may express what is in a message, which should deal with it,
whether it is optional or mandatory, and transaction control. The message is in the body
part. SOAP defines request messages and response messages for remote method
invocation.

The SOAP binding framework defines an abstract framework for exchanging SOAP
envelopes between peers using an underlying protocol for transport. The SOAP HTTP
binding defines a concrete instance of a binding to the HTTP protocol.

The SOAP encoding rules defines a serialization mechanism that can be used to exchange
instances of application-defined data types.

The SOAP remote method representation defines a convention that can be used to
represent remote procedure calls and responses.
These four parts are functionally orthogonal. In recognition of this, the envelope and the
encoding rules are defined in different namespaces to distinguish their roles.
8
The SOAP remote method-marshalling format is XML
[3][10]
, which is a universal format for
structured documents and data on the Web. XML Schemas express shared vocabularies and
allow machines to carry out the validation of XML messages. XML Schemas provide a means
for defining the structure, content and semantics of XML documents. This XML Schema
Definition include what elements are (and are not) allowed at any point; what the attributes for
any element may be; the number of occurrences of elements; etc. By using the XML Schema
Definition associated with XML data, a parser can automatically validate the data by its structure
and logical composition.
2.4.
WSDL (Web Service Description Language) [5][11]
WSDL is an XML format for describing network services as a set of communication endpoints
operating on messages containing either document-oriented or procedure-oriented information.
WSDL provides an abstract way to describe the capabilities of Web Services. WSDL reveals the
SOAP request and response formats of a Web Service. WSDL also defines a service’s binding to
a network transport protocol, usually HTTP.
The WSDL description published by Web Services can be used to automatically generate stub
routines for the development of SOAP clients within a specific programming environment.
A WSDL document uses the following elements in the definition of network services:

Types: a container for data type definitions using some type system (such as the built-in
primitive XML Schema types or a user-defined XML Schema type system).

Message: an abstract, typed definition of the data being communicated, usually the
request and response messages associated with a particular remote method call.

Operation: an abstract description of an action supported by the service, such as the
remote methods of a service.

Port Type: an abstract set of operations supported by one or more communication
endpoints of a service.

Binding: a concrete protocol and data format specification for a particular port type.

Port: a single endpoint defined as a combination of a binding and a network address.

Service: a collection of related endpoints.
9
2.5.
UDDI (Universal Description, Discovery, and Integration) [6]
UDDI is a specification for an Internet-wide registry of Web Services and their metadata. The
UDDI project creates a platform-independent, open framework for describing services,
discovering businesses, and integrating business services using the Internet, as well as an
operational registry that is available today. The metadata contains information about the
company offering a given service and technical details on how it can be accessed through a
WSDL description of the service.
SOAP, WSDL and UDDI work together in a three-folds service architecture (Fig. 1). Service
providers publish their services in a UDDI registry. A service requester finds the service from the
UDDI registry and makes call to the provider to process a SOAP transaction. The service’s
WSDL interface describes the appropriate request and responses that the service supports.
Service broker
Step 1
Step 2
UDDI registry
Step 3
Service provider
Service requester
Step 4
Servers
Desktop browser
Step 5
Fig.1 The Web Service Model
Step 1: A service provider registers its service with a registry that is maintained by a service broker. The
service broker represents a set of software interface for published Web services.
Step 2: The requester makes a call to the broker’s UDDI registry, seeking a desired service and
instructions how to call it.
Step 3: Once the requester finds the right service, the service broker returns the service’s location details
to the requester.
Step 4: The requester is ready to invoke the service by making a SOAP call to the service provider.
WSDL describes the request’s format, the parameters and the data type.
Step 5: The provider delivers the Web Service application results to the requester. The transaction is
complete.
10
2.6.
P2P (Peer-to-Peer)
Web Service technologies are not necessarily client-server oriented and may adopt a P2P
computing model in which Web Services act as peers by implementing both client and server
aspects in their functionality. Napster and Gnutella are examples of distributed resource sharing
architectures based on the P2P model.
In fact, P2P computing is not new. It has been around for more than 30 years. P2P is the sharing
of computational resources and information through a direct exchange between systems. A P2P
model is different from the traditional client-server model because the peers cannot be
distinguished as pure clients and servers. That is, peers are able to request information from other
peers and serve requests by other peers. So peers have the ability to act as servers and respond to
requests but can also request services from other peers.
2.6.1. Characteristics of a P2P Architecture
Discovering other peers
A peer must be able to find other peers that are willing to share information. A traditional way to
find other peers is to check a central server, which maintains a list of all resources currently
available to share. This is for example how Napster [12] works.
Querying peers for content or service
After the peers have been discovered, they should listen to the requests and provide
corresponding services according to the requests.
Sharing content or service with other peers
A peer cannot only request other peer services; it must share its own services and resources with
other peers by listening to their requests.
2.6.2. P2P Models
Pure P2P
Pure P2P model has no center server. (Fig. 2) It dynamically discovers other peers on the
network and interacts with each of them for sharing services. The strength of this type is that it
doesn’t rely on one server to be available for registration and finding which avoid the problem of
11
one-site-failure. The problem is that only a small number of peers can be found at one time
without the help of center server. And with the increment of the number of peers discovered the
load of network increased. The number of connections is:
n!
(n  2)!2!
Peer
Peer
Peer
Fig. 2 Pure P2P model
P2P with a simple discovery server
This model works like Pure P2P models but it has a center server for the discovery of other
peers. (Fig. 3) In this model, a peer registers its services on the central server. The peer then uses
the central server to get the list of the other peers’ services and contacts each other individually
with its request. An example is Napster.
[12]
This model is easier to get a large number of peers
compared to the Pure P2P model. But the reliance on a center discovery server causes a singlepoint-of-failure problem.
12
Server
Peer
Peer
Peer
Fig. 3 P2P with a Simple Discovery Server
P2P with a discovery and content server
In this model, each peer can upload/download the whole content of services to the central server.
This approach effectively becomes a client-server model because the peers no longer need to
contact with each other but get everything through the central server. The problem of this model
is the possibility of a single-point-of-failure and the load of the central server may be heavy and
this could cause network congestion in the proximity of the central server.
Server
Peer
Peer
Peer
Fig. 4 P2P with a Discover and Content Server
13
2.7.
Industry Support for Web Service and P2P
2.7.1. Microsoft .NET [7]
To support the development of Web Service, Microsoft will publish their new generation of
Development solution: Visual .NET. The Visual .NET will be available on February of 2002.
Now the Beta 2 test version is available to download from Microsoft’s Web site. Visual .NET
borrows the idea of the virtual machine from Java (JVM) but with some differences. One of the
differences is that applications created by Visual .NET do not need to add entries to a system
registry for remote method invocation unlike Java RMI. The Visual .NET development
environment is available for a multitude of programming languages, for example C#, Visual
Basic, C++, and Haskell. The languages adopt the Common Language Runtime (CLR) for
managed objects. The managing of objects makes remote method invocation easy and hidden to
the programmer.
Web Service
Container
Client Tier
Web Services
created in either
J2EE or .NET
XML/SOAP
Desktop Browser
HTML/XML
Service Creation and Assembly
32 CLR (Common Language Runtime)
supported languages (including C#,
JavaScript, and Visual Basic .NET)
.NET Application
Smart Phone
WML/XML
Passport .NET,
HailStorm
XML/SOAP
ASP
.NET
.NET managed
components
Runtime Environment and Platform:
CLR on Win32
Back-end
Systems
ADO .NET
Database
Management
System
Microsoft Host
Integration
Server
Legacy
Applications
XML, SOAP,
WSDL, UDDI,
BizTalk Server
Web Services
Fig. 5 Microsoft .NET Web Services
2.7.2. Sun ONE
Sun Microsystem’s Sun ONE (One Net Environment), powered by J2EE (Java 2 Enterprise
Edition), offers a cross-platform solution for developing Web Services [8] based on Java.
14
Web Service
Container
Client Tier
Web Services
XML/SOAP
Browser
HTML/XML
Back-end
Systems
Services Creation and Assembly
Java IDE (Forte, VisualAge) and Web
Service APIs (JAXB, JAXM, JAXR,
and JAX-RPC)
Servlets
EJBs
JDBC
Database
Management
System
JMS
connectors
Legacy
Applications
XML/SOAP
Web Services
JSPs
Smart Phone
WML/XML
Runtime Enviroment and Platfor
JRE running on any of multiple OSs,
including Linux, Solaris, and Windows
Fig. 6 Sun ONE Web Services
2.7.3. Sun JXTA
Sun also has a project named JXTA for P2P computing. JXTA is a set of open, generalized peerto-peer protocols that allow any connected device (cell phone, to PDA, PC to server) on the
network to communicate and collaborate[9]. JXTA defines a series of XML message formats and
protocols for communicating between peers in a structured fashion. These are as follows:

Resolver Protocol: used to wrap any query / response messages used to match tags in
advertisements.

Discovery Protocol: used to discover advertisements on other peers which specify peers /
peer groups / services;

Information Protocol: protocol for querying peer status (up time etc.)

Pipe Binding Protocol: used by peer group members to bind a pipe advertisement to a
pipe endpoint.

Endpoint Resolution Protocol: used by peers to find routes to other peers. Peers send
requests for routes to peer routers using Endpoint and receive responses containing the
routes to the requested peer.

Endpoint Routing Protocol: used to route messages from one peer to another.

Membership Protocol: used by a peer to join / leave groups

Propagation Protocol: used by peers to send messages around a peer group.
15
3. Design of the P2P Computing Infrastructure with SOAP
In this section the design of the P2P computing infrastructure with SOAP is presented. Several
key design issues contributed to the implementation.
General Design:

The design adopts the 2nd model of P2P computing, however, by using multiple servers
for discovery thereby forming clusters of P2P networks connected through cluster
servers. This avoids the problems associated with single centralized discovery service
such as a single-point-of-failure and congestion of the single server.

Four types of applications: a Client Agent for lookup, a Service Agent for discovery, a
Service Provider to provide Web services, and a Statistics Provider for providing optional
usage statistics of a Web Service (used to optimize load).

Client Agent: runs locally to serve lookup requests by clients. It maintains a cached
list of the description of Web Services available on the P2P network. A client lookup
operation returns the communication endpoint of a service provider which provides
the service that the client requests. The Client Agent needs to know the
communication endpoint URL of the default Service Agents to obtain a list of
endpoints of Service Providers by sending requests

Service Agent: a replicated central Discovery server that maintains a registry of
Service Providers, so that the Client Agent knows the endpoints of the Service
Providers.

Service Provider: an organization that provides the Web Services. It maintains a
description of Web Services running locally or remotely so the Client Agent knows
what Web Services are provided by this Service Provider.

Statistics Provider: a server provides the statistic information about service usage to
the Client Agent.

Three files served as database:

HD file: located on Service Agent. Its contents include the endpoints and time stamps
of WS file on a Service Provider in the P2P network.
16

WS file: located on Service Provider of the P2P network. It contains the description
about the Web Services this Service Provider provides. It may also contain the
description of Web Services of another Service Provider if that Service Provider
doesn’t have such file on it. (For example, a Web Service running on a Service
Provider designed by other policies can be added to the P2P network)

Statistic file: located on Statistic provider. It contains the statistic usage of a Web
Service.
For the first two files, the time stamp of a file is read from the server first to check if the
file is updated since last access. This saves some network communication by aborting the
attempt of reading the same file from server again.
In this demo program, all the three files are saved as a text file on hard disk. The files can
also be other forms, like real database in a large-scale system.

Service Provider is an organization in the P2P network, which provides Web Services.

Every peer in the P2P network has one Client Agent it can connect to.

The Client Agents use local caches with registry information.

One Service Provider in the P2P network can have multiple Web Services.

One Web Service can have multiple remote methods.

Each Client Agent connects to one default Service Agent to request registration
information.

Each Service Provider connects to one default Service Agent to do registration
17
Web
Service
1
2
Client
Client
Agent
5
Service
Provider 1
Organization 1
1
6
3
Service
Agent
1
3
Service
Provider 2
4
6
Web
Service
2
Statistic
Provider
Organization 2
Fig. 8 Design of the Project
Step 1: Each Service Provider connects to a (default) Service Agent to register its existence at it’s
startup. The registration information includes the endpoint of this Service Provider and
the time stamp of WS file, which contains the description of Web Services, on this
Service Provider. A Service Provider also needs to send the information to the Service
Agent periodically after startup to inform its availability.
The Service Agent connects to each Service Provider on its registration list to check the
time stamp and the availability of the Service Provider. If such connection failed, the
Service Agent removes that provider from its list. That provider is added to the Service
Agent receives its registration information. This is why a Service Provider needs to resend the registration periodically.
Step 2: At first, a Client Agent doesn’t have the knowledge of the endpoint of all Service
Providers in the P2P network. It only knows the endpoint of a default Service Agent and
maybe some providers. It makes a request to the Service Agent at startup for the list of all
18
Service Providers in the network. And it also checks the Service Agent for the same list
periodically after startup. By this way, the Client Agent keeps up-to-date information
about the Service Providers.
Step 3: After the Client Agent gets the list of Service Providers, it connects to each Service
Provider to request the contents of WS file, which contains the description of Web
Services provided by this provider.
Step 4: The Client Agent requests the statistic usage of one Web Services from Statistic
Provider. After Step 4, the Client Agent has the knowledge about all the web services in
the network. It saved the description of a web service like this:
s_name:
magich
s_nameSpace: ns1
s_endPoint:
linprog2.cs.fsu.edu:18081
s_action:
demo_action
s_wsFile:
linprog2.cs.fsu.edu:18300
l_time:
1006827691
s_statUrl:
linprog2.cs.fsu.edu:18400/statms.txt
i_usage:
6
// time stamp of ws file
// statistic usage
Step 5: While the client wants to invoke a Web Service, it asks the Client Agent where to find the
service it wants. The Client Agent search through the list of descriptions of Web Services
and returns an endpoint of a Service Provider to the client. So the client can contact the
Service Provider for the service.
Step 6: The Statistic Provider should know the current (or most current) usage of Web Services.
This can be done by invoke a method by the Web Service after each access from the
client. Or the Statistic Provider invokes a method to monitor the Internet access to each
Web Service.
A step not shown on the graph is for the Service Agent, it pushes its list of Service Provider
registration information to another Service Agent. There are several Service Agents
running in the network and each Service Provider and Client Agent only connects to a
default one to do the registration and requests. How the Client Agent gets the description
of Web Services provided by a Service Provider, which connects to another Service
19
Agent. This is solved by the information forwarding between the Service Agents. Once a
Service Agent updates its list of Service Provider, it pushes the updated information to
another Service Agent. So for one Service Agent, its list contains all the Service
Providers in the network no matter those providers connects to this agent directly or not.
3.1.
Application Feature
3.1.1. Register and maintain list of Service Providers
A Service Provider registers its endpoint and time stamp to the Service Agent during startup.
And re-send the register information periodically to tell the Service Agent it is still alive. The
Service Agent keeps a list of active Service Providers by connecting those Service Providers
periodically. If a connection failed, that Service Provider is not active. The Service Agent will
remove that Service Provider from the list. The Service Provider is added to the Service Agent
again when it restarts or when it re-sent the registration information.
3.1.2. Discover
Client Agent downloads the list of Service Providers from the Service Agent and connects to
each of them to download the services information of that Service Provider.
3.1.3. Query
Client Agent get request from Client. Find the appropriate service in the database and return the
information to the Client.
3.1.4. Sharing
A Service Agent shares its information with other Service Agents. A site shares its services with
other sites.
20
4. Implementation of the P2P Infrastructure with SOAP
In this section the implementation of the P2P infrastructure with SOAP is discussed.
4.1.
The gSOAP Stub and Skeleton Compiler for C and C++
The gSOAP stub and skeleton compiler for C and C++ was developed at Florida State
University. The gSOAP compiler enables applications written in C and C++ to share
computational resources and information with other applications over the Web with SOAP. The
compiler generates remote method stubs and skeletons in C++ source code, which can be used
by peers, clients, and Web Service applications written in C/C++.
4.2.
gSOAP Example
An example of the gSOAP stub and skeleton compiler is illustrated below.

magic.h
int ns__magic ( int rank, matrix &result );
The last parameter is always used to hold the return value.

smagicclient.cpp
main()
{
int r = rand() % 20;
matrix A;
soap_call_ns__magic(“linprog1.cs.fsu.edu:18081”,NULL,r,A)
}
struct Namespace namespace[] =
{
{“SOAP_ENV”, “http://schema.xmlsoap.org/soap/envelop/”,
{“SOAP_ENC”, “http://schema.xmlsoap.org/soap/encoding/”},
{“xsi”, “http://www.w3.org/2001/XMLSchema-instance”},
{“xsd”, “ http://www.w3.org/2001/XMLSchema”},
{“ns”, “urn:magic”};
{NULL, NULL}
}
21
The four parameters in soap_call_ns__magic() are: the endpoint of the Web Service, the
action of the Web Service, the input parameter, and the return value.
4.3.
Types and Data Structures used by the P2P Agents
In order to obey the convention of XML and SOAP compiler, there are some types and data
structures used in the code. Here is the list. Those types will not be explained again in the later
parts:
typedef char * xsd__NCName: XML type, used to declare name of remote method
typedef char * xsd__anyURI: XML type, used to declare the URL (endpoint)
typedef char * xsd__string: XML type, used to declare other string type
typedef long xsd__long: XML type, used to declare long integer
struct ns1__remoteMethodLookupRequest
{
xsd__anyURI endpoint;
xsd__string action;
};
This structure is used to hold the result of remote method lookup request. The member data
represent the endpoint and action of the service the client wants. The result is passed from the
Client Agent to the client by reference.
class ns1__SiteTime
{
xsd__anyURI endpoint;
xsd__long lastUpdate;
};
The two data members are the endpoint of a Service Provider and the time of the last update of
the Service Provider.
22
class ns1__ArrayOfSiteTime
{
ns1__SiteTime *__ptr;
int __size;
};
This class is used to save the result of reading of HD file on the Service Agent. The first data
member is a pointer to the array of ns1__SiteTime objects, in which each element represent one
Service Provider and the time of its last update. The second one is the size of the array, the
number of Service Providers.
class ns1__RM: This class is used to save the information of one Web Service, including the
name, name space, endpoint, action, etc.
class ns1__ArrayOfRM
{
ns1__RM *__ptr;
Int __size;
};
This class is used to save the contents of one WS file, which contains the information about Web
Services that one Service Provider provides. The first member data is a pointer to an array of
ns1__RM objects. The second one is the size of the array.
class ns1__WS
{
xsd__long lastUpdate;
ns1__ArrayOfRM methods;
};
This class is used to save the result of reading of WS file on a Service Provider. The first
member data is the time of last update of the WS file. The second one is the contents of the WS
file, which have been saved as an array of ns1__RM objects.
23
class matrix: This class is used to hold the result of matrix calculation request.
struct TimeCell: The structure of a site and the time of its last update.
class Md: The class of local data maintained by the class AgentLocal. Each object represents the
information of one registered Web Service.
4.4.
Client
The client works only as a client side program. When the client need to call a remote method
running on a Service Provider in the P2P network, it needs to make two steps to finish this work.
First, it makes a request to the Client Agent to find the endpoint of the remote method. The client
then connects to the Web Service provided by the endpoint and makes the remote method call.
Corresponding to these two steps, the client makes two remote method calls through a SOAP
socket:
soap_call_ns1__RemoteMethodLookup( AGENT_URL, NULL, “magics”, “magic”, response )
There are five parameters for this function call:

AGENT_URL: the endpoint (URL) of the Web Service

NULL: the action of the Web Service

“magics” and “magic”: the name and name space of the Web Service

response: an object of the structure ns1__remoteMethodLookupResponse. The structure
contains the return value of the client request.
The SOAP socket uses the first two parameters to setup the connection. The last three parameters
are used by the remote method as parameters. And in the last three parameters, the first two are
input parameters and the third one holds the return value.
After the client get the endpoint and action of the remote method, the client tries to make a
connection to the Service Provider to invoke the Web Service on that Service Provider. In this
example, calculating the matrix:
24
soap_call_ns2__magic( response.endpoint, response.action, r, A )
In the four parameters:

The first two are used to make the connection through soap socket. They are obtained
from the Client Agent through the previous remote method call. response is the return
value from the Client Agent in the first remote method call.

r: an integer, the size of the matrix

A: an object of the class matrix, holding the result of the calculation of the Web Service.
After these two steps, the client gets the result of the calculation though it doesn’t do the
calculation directly and it doesn’t know where to get the result.
4.5.
Client Agent
The Client Agent has two major functions: listening to the requests from Client and requesting
information Web Services from the Service Agent, Service Providers and Statistic Providers. In
order to fulfill the two functions at the same time, the Client Agent generates two threads to run
the server side functions and client side functions separately.
4.5.1. agent.cpp
This is the main program of Client Agent. It generates two threads to listen the clients’ requests
and run the local functions with an object of AgentLocal class.
It contains the following functions:
main()
The function generates another thread to run some server functions. Those server functions
include: soap_accept() to listen requests, soap_serv() to invoke proper server functions
according to the request and soap_end() to return the result of the request and terminate the soap
socket communication.
In the main thread, the program creates an object of AgentLocal class to run the client side
function and some other local functions for the local data maintenance.
25
int ns1__remtoeMethodLookup ( xsd__NCName name,
xsd__anyURI URI,
struct ns1__remtoeMethodLookupResponse {
xsd__anyURI endpoint;
xsd__string action;
} &response )
This is the definition of the remote method for client request. There are three parameters:

xsd__NCName name: the name of the requested Web Service.

xsd__anyURI URI: the name space of the requested Web Service, which can be NULL if
the client doesn’t want to specify the value.

struct ns1__remoteMethodLookupResponse &response: the return value, which includes
the endpoint and the action of the Web Service.
The remote method lookup is based on the usage of remote method if there are more than one
Web Service with the same name and name space. The Client Agent returns the Web Service
with the greatest usage.
4.5.2. Class AgentLocal
This is the class to do the requests and other local functions. It has two member data:
v_time: a vector. Each element in the vector is an object of structure TimeCell, which has the
time stamp of the last update of WS file on a Service Provider.
v_md: a vector: Each element in the vector is an object of class Md, which has the detailed
information of a Web Service.
It defines the following member functions:
void readFile()
26
Reading the local cached file, which is saved on the hard disk as a file, at the startup time to get
the endpoint of the default Service Agent and the endpoints of Service Providers in the P2P
network which were active during the last update.
void writeFile()
Writing the endpoint of default Service Agent and the endpoints of Service Providers, which are
currently active in the P2P network, to the local cached file saved on the hard disk.
void connectToHost()
Connecting to the default Service Agent to read the HD file on it. The HD file contains the
endpoint and time stamp of each Service Provider in the P2P network. If the Service Agent
added any new Service Providers to its list or changes the time stamp of any Service Providers,
the Client Agent modifies its list the same way. If the Service Agent removed any Service
Providers from its list, the Client Agent degrades the statistic usage of all the Web Services that
Service Provider provides. There are two remote method calls to implement the work:
soap_call_ns1__getFileTime( url, NULL, newTime );
This remote method call is used to get the time of the last update of HD file on the Service
Agent and compares with the time saved in the local time vector. If there is no new update,
the Client Agent doesn’t need to read the contents of the HD file.
The four parameters are:

url: the endpoint of the Service Agent.

NULL: the action of the Service Agent.

newTime: the time of the last update of HD file. This is the return value from the
Service Agent.
If there’s any changes of the HD file since last access by Client Agent, the Client Agent reads the
new contents of the HD file. This is done by the following function:
soap_call_ns1__readHdFile ( url, NULL, contents );
27
This remote method call is used to get the contents of the HD file on the Service Agent. The
parameters are:

url: the endpoint of the Service Agent.

NULL: the action of the Service Agent.

contents: an object of class ns1__ArrayOfSiteTime. It holds the result of reading the
HD file on Service Agent. The member data are: a pointer to an array of
ns1__SiteTime objects and the size of the array.
After this remote method call, the Client Agent gets the contents of the HD file on the Service
Agent. After that, the Client Agent updates the local time vector and degrades the non-active
Service Provider. After that, the Client Agent connects to each Service Provider on the list to get
the details of Web Services that Service Provider provides by reading the WS file on the Service
Provider.
void connectToService()
Connecting to the Service Provider to get the details of Web Services that Service Provider
provides by reading the WS file on it. The WS file contains the information that Client Agent
need to know about the Web Services that Service Provider provides, including the name, name
space, endpoint, action, endpoint of usage, etc. By the attempt of connection, the Client Agent
knows if that Service Provider is still active or not, if there’re new Web Services added to the
server. And the Client Agent modifies its own service vector, according to the changes on the
Service Provider, to keep the up-to-date information.
The procedure is the same as connectToHost(): First check the time of the last update of WS file
on the Service Provider. If that file changed, then read the contents of the file. The two remote
procedure calls are:
soap_call_ns1__getFileTime ( url, NULL, newTime );
This function gets the time stamp of last update of WS file. This is similar as the method
used in connectToHost(). The url here is the endpoints of the Service Provider. The newTime
is the time of last update of the WS file and returned to the Client Agent for comparing.
28
soap_call_ns1__readWSFile ( url, NULL, ws );
This function reads the WS file on the Service Provider pointed by url and returns the
contents of the WS file as an object of ns1__WS. The parameters are:

url: The endpoint of the Service Provider

NULL: The action of the Service Provider

0: empty input parameter

ws: an object of ns1__WS, saves the contents of the WS file and returns to the Client
Agent.
The WS file doesn’t contain the usage of each service but an endpoint, pointing to the
Statistic Provider, which contains the usage for each service. To retrieve the usage, the Client
Agent makes another remote method call to the Statistic Provider.
void connectToStat()
This function makes a connection to the Statistic Provider to get the statistic usage of a Web
Service. The statistic usage can be save in a file or loaded in the memory.
The remote method call is:
soap_call_ns1__readStatFile ( endpoint, NULL, pathName, rate );
The four parameters are:

endpoint: the endpoint of the Statistic Server

NULL: the action of the Statistic Server

pathName: The name of the file, which has the statistic usage of a service, and the
relative path to the file.

rate: an integer holding the statistic usage of a service and return to the Client Agent.
The separation of Statistic Server from Service Provider makes it possible for the Client Agent to
check only the statistic usage more frequently than check the whole information of Web
Services. This reduces the load of network communication and avoids the possibility of network
congestion.
There are also some other member functions to maintain the local data structure.
29
4.6.
Service Agent
The Service Agent works as an endpoint-time registration center. It keeps the endpoint of all
active Service Providers in the P2P network and the time stamp of the last update of WS file of
each Service Provider.

It listens for the request from Client Agent and returns the endpoint-time information to
the Client Agent so the Client Agent can get the knowledge which Service Provider is
still running and when did they make the last update.

It listens for the request from a Service Provider to register a new Service Provider to its
list.

It listens for the request from another Service Agent to get the forwarded site-time list
from that Service Agent.

It also works as a client. It makes a request to each Service Provider periodically to check
if that Service Provider is still active and the new time stamp of the WS file on that
Service Provider.

It also pushes the updated site-time list to another Service Agent.
For these functions of the Service Agent, a multi-threads solution is necessary.
4.6.1. host.cpp
This is the main program of Service Agent. The same as agent.cpp, in the main() function,
host.cpp generates another thread to run some server functions which include soap_accept(),
soap_serv() and soap_end(). In the main thread, an object of class HostLcoal is created to run the
client functions and other local maintenance functions.
The other functions defined in host.cpp include:
int ns1__getFileTime ( long &newTime );
This function returns the time stamp of HD file on the Service Agent.
int ns1__readHdFile ( ns1__ArrayOfSiteTime &contents );
30
This function returns the contents of HD file as an object of class ns1__ArrayOfSiteTime. The
HD file contains the endpoint and time stamp of each active Service Provider in the P2P
network.
int ns2__regSite ( ns1__SiteTime reg, int &a );
Called by the Service Provider to register itself, the endpoint and time stamp, to the Service
Agent. The parameters are:

ns1__SiteTime reg: the registration information sent to the Service Agent by a Service
Provider. The information includes the endpoint and time stamp of a Service Provider.

int &a: an empty integer as return value to keep the compatibility with different
development environments.
int ns2__setUpdate ( ns1__ArrayOfSiteTime vTime, int &a );
This function is called by another Service Agent to send the updated site-time information to this
Service Agent. So the two Service Agents can keep the same information of Service Providers in
the P2P network.

ns1__ArrayOfSiteTime vTime: the vector of site-time information sent to this Service
Agent by another Service Agent. It includes the endpoint-time pair for several Service
Providers.

int &a: an empty integer as return value used to keep the compatibility with different
development environments.
4.6.2. Class HostLocal
This class deals with the requests to other servers, other Service Agents and Service Provider,
and the local data maintenance. The useful member data declared here is:
v_time: a vector of objects of structure TimeCell. It saves the site-time information.
The member functions defined here includes:
31
void readFile();
Reading the HD file at the initialization. The HD file contains the site-time information of active
Service Providers in the P2P network.
void writeFile();
Writing the site-time information of active Service Providers in the P2P network to HD file
void connectToService();
Try to connect to each Service Provider in the list and get the new time stamp of the WS file on
that Service Provider periodically. If the connection attempt failed, it means the Service Provider
is not available at this time. The Service Agent removes this Service Provider from its list. If
succeeded, the Service Agent compares the new time stamp with the one saved in the endpointtime vector and decides if it needs to update the endpoint-time vector.
The remote method call used here is:
soap_call_ns1__getFileTime ( url, NULL, newTime );

url: the endpoint points to the Service Provider the Host wants to visit.

newTime: the time stamp of the WS file on the Service Provider.
void connectToHost()
This function connects to another Service Agent to push the endpoint-time vector if there’s any
update. By this way, the endpoint-time vector between different Service Agents keeps
synchronized. If there is no update of the time vector, the Host doesn’t need to call this function
to push the time vector to another Service Agent. This avoids the infinite loops of pushing
between Service Agents.
The remote method call used here is:
soap_call_ns2__setUpdate ( url, NULL, vTime, a );

url: the endpoint points to another Service Agent

NULL: action

vTime: the updated local time vector.

a: an integer of return.
32
4.7.
Service Provider
This is the server providing Web Services. It also contains a WS file describing the detailed
information of Web Services in most cases. There are some situations that a Service Provider
doesn’t have such file on it. This is because of the different design policies or some other
reasons. For example, a site wants to provide a Web Service that not maintained by it. The
information of the Web Services provided by such sites may be saved in the WS file of other
Service Providers. For the example of above, the site get the permission from the Service
Provider and adds the information about that Web Service to the WS file of its Service Provider
and provides corresponding methods to monitor the usage of that Web Service. In such situation,
the site is more like an Agent, which provides the information about how to access a remote Web
Service.
The functions of the Service Provider include:

The Service Provider listens to the request from Client Agent and returns the contents of
WS file as an object of ns1__WS.

The Service Provider listens to the request from client to invoke the proper remote
methods if the methods located in this server.

The Service Provider listens to the request from Service Agent and returns the time stamp
of WS file.

The Service Provider sends request to the Service Agent to register endpoint-site
information periodically.
The functionality of the Service Provider makes it works both as server and client at the same
time. The multi-threading is necessary here to support that.
4.7.1. serv.cpp
This is the main program of Service Provider. Like the Client Agent, the main() generates
another thread to run some functions about server which include: soap_accept(), soap_serv() and
soap_end(). And in the main thread, an object of class ServLocal is created to deal with the client
functions and local data maintenance.
33
Other server functions defined here include:
int ns1__getFileTime ( long &newTime );
This function returns the time stamp of WS file on this Service Provider.
int ns1__readWSFile ( ns1__WS &ws );
Returns the contents of WS file as an object of class ns1__WS.
4.7.2. Class ServLocal
This is the class dealing with the client functionality and local data maintenance. The member
functions of the class include:
void connectToHost();
This function connects to the Service Agent to register this site at startup and periodically after
that. So the Service Agent knows this Service Provider is still running and the newest time stamp
of the WS on this Service Provider. The remote method call used here is:
soap_call_ns2__regSite ( hostUrl, NULL, reg, a );

hostUrl: the endpoint points to the Service Agent

NULL: action

reg: an object of ns1__SiteTime, which include the endpoint of this Service Provider
and the time stamp of the WS file on this Service Provider.

a: an integer for the return.
There are also some other functions to support the running of the ServLocal class.
4.8.
Statistics Provider
This is the server where to find the statistic usages of Web Services. It listens to the request from
the Client Agent and returns the statistic usage of the service requested.
34
There are many different ways to save the statistic usage of services: The statistic usages can be
save as files which is used in the demo program. One file contains the statistic usage of one
service. Or it can be save in memory as a vector whose element is a pair of service name and
service usage. Or for large scaling system, it may be a real database system running at back-end
to save the statistic usage.
The server function defined here is:
int ns1__readStatFile ( xsd__string fileName, int &rate );

xsd__string fileName: the path and the name of the file containing the statistic usage. One
file only contains the usage of one service. So the Client Agent need to specifies which
file to read.

int &rate: an integer saving the statistic usage reading from the file and returning to the
Client Agent.
35
5. Results
5.1.
Parts of the Code of smagicclient.cpp
int main(int argc, char **argv)
{
int r;
if (argc <= 1)
r = rand()%20;
else
r = atoi(argv[1]);
struct ns2__remoteMethodLookupResponse response;
if ( soap_call_ns2__remoteMethodLookup ( AGENT_URL, NULL,
"ns1", response) )
exit (-1);
"magich",
printf ( "response.endpoint: %s\n ", response.endpoint );
matrix A;
if ( soap_call_ns1__magic( response.endpoint, NULL, r, A ) )
exit (-1);
for (int i = 0; i < A.__size; i++)
{
for (int j = 0; j < A[i].__size; j++)
printf("%4d", A[i][j]);
printf("\n");
}
return 0;
}
The magic client doesn’t knon the endpoint of the magic server (the Web Service), but it can get
that from the Client Agent by requesting.
5.2.
The Result of Service Agent:
yunwwang@linprog2.cs.fsu.edu:C++/Agent/Host>hostw
36
Socket connection to linprog2.cs.fsu.edu:18200 was successful // socket binding
Host::ns2__regSite()
// the Service Provider1 register it endpoint-time info.
Host::showVTime()
linprog2.cs.fsu.edu:18300 1006825348
Host::ns2__regSite()
// the Service Provider2 register it endpoint-time info.
Host::showVTime()
linprog2.cs.fsu.edu:18300 1006825348
linprog3.cs.fsu.edu:18301 1006824771
HostLocal::connectToHost()
// forward the list to another Service Agent
HostLocal::connectToService() // check the new time stamp of each Service
// Provider
Host::showVTime()
linprog2.cs.fsu.edu:18300 1006825348
linprog3.cs.fsu.edu:18301 1006825361
HostLocal::connectToService() // check the new time stamp of each Service
// Provider
Host::showVTime()
linprog2.cs.fsu.edu:18300 1006825348
linprog3.cs.fsu.edu:18301 1006825361
Host::ns1__getFileTime()
// Client Agent request the time stamp of HD file
Host::ns1__readHDFile()
// Client Agent read the HD file
HostLocal::connectToService() // check the new time stamp of each Service
// Provider
Host::showVTime()
linprog2.cs.fsu.edu:18300 1006825348
linprog3.cs.fsu.edu:18301 1006825361
Host::ns1__getFileTime()
// Client Agent reqeust the time stamp of HD file
// Because no update of the HD file, the Client
// Agent doesn’t need to read the HD file again.
HostLocal::connectToService() // check the new time stamp of each Service
// Provider
Host::showVTime()
5.3.
The Result from Service Provider:
Socket connection to linprog2.cs.fsu.edu:18300 was successful 3
ServLocal::connectToHost()
// register the Service Provider to the Service Agent
Serv::ns1__getFileTime()
// Service Agent requests the time stamp
Serv::ns1__getFileTime()
// Service Agent requests the time stamp
Serv::ns1__getFileTime()
// Client Agent reqeust the time stamp
Serv::ns1__readWsFile()
// Client Agent reqeust the contents of WS file
ws.lastUpdate: 1006825348
// the value of ws object
ws.methods.__ptr.methodName: print // Web Service: print
ws.methods.__ptr.mehtodURI: ns3
ws.methods.__ptr.endpoint: linprog2.cs.fsu.edu:18300
37
ws.methods.__ptr.wsdlURL: demo_wsdl
ws.methods.__ptr.soapAction: demo_action
ws.methods.__ptr.statURL: linprog2.cs.fsu.edu:18400/statpri.txt
ws.methods.__ptr.methodName: magich
// Web Service: magich
ws.methods.__ptr.mehtodURI: ns1
ws.methods.__ptr.endpoint: linprog2.cs.fsu.edu:18081
ws.methods.__ptr.wsdlURL: demo_wsdl
ws.methods.__ptr.soapAction: demo_action
ws.methods.__ptr.statURL: linprog2.cs.fsu.edu:18400/statms.txt
Serv::ns1__getFileTime()
Serv::ns1__getFileTime()
5.4.
The Result of Statistic Provider:
yunwwang@linprog2.cs.fsu.edu:C++/Agent/Stat>statw
Socket connection to linprog2.cs.fsu.edu:18400 was successful 3
// binding
Stat::ns1__readStatFile()
// Client Agent read the statistic usage.
5.5.
The Result of Client Agent:
yunwwang@linprog1.cs.fsu.edu:C++/Agent/Agent>agent
Socket connection to linprog1.cs.fsu.edu:18100 was successful 3
// binding
AgentLocal::connectToHost() // Request the list of Service Provider from Service
// Agent
** Connecting to Host linprog2.cs.fsu.edu:18200
** Server file changed. Get new file contents from server.
AgentLocal::showTime()
linprog2.cs.fsu.edu:18200 1006827711
linprog2.cs.fsu.edu:18300 -1
linprog3.cs.fsu.edu:18301 -1
AgentLocal::connectToService() // Request the infor of Web Services from Service
// Provider
** Get new WS file from Service server
AgentLocal::addService()
// Add Web Services to the local vector
** Get new WS file from Service server
AgentLocal::addService()
// Add Web Services to the local vector
AgentLocal::connectToStat()
// Request the statistic usage from the Statistic
// Provider
AgentLocal::showVMd()
// Show the content of local vector
s_name: print
// Web Service: print
s_nameSpace: ns3
s_endPoint: linprog2.cs.fsu.edu:18300
s_action:
demo_action
s_wsFile:
linprog2.cs.fsu.edu:18300
l_time:
1006827691
38
s_statUrl:
linprog2.cs.fsu.edu:18400/statpri.txt
i_usage:
5
s_name: magich
// Web Service: magich
s_nameSpace: ns1
s_endPoint: linprog2.cs.fsu.edu:18081
s_action:
demo_action
s_wsFile:
linprog2.cs.fsu.edu:18300
l_time:
1006827691
s_statUrl:
linprog2.cs.fsu.edu:18400/statms.txt
i_usage:
6
s_name: magich
// Web Service: magich. The same as above but on
// different server
s_nameSpace: ns1
s_endPoint: linprog3.cs.fsu.edu:18081
s_action:
demo_action
s_wsFile:
linprog3.cs.fsu.edu:18301
l_time:
1006827704
s_statUrl:
linprog3.cs.fsu.edu:18400/statms.txt
i_usage:
3
s_name: write
// Web Service: write
s_nameSpace: ns3
s_endPoint: linprog3.cs.fsu.edu:18300
s_action:
demo_action
s_wsFile:
linprog3.cs.fsu.edu:18301
l_time:
1006827704
s_statUrl:
linprog3.cs.fsu.edu:18400/statwri.txt
i_usage:
7
Agent::ns1__remoteMothodLookup
// smagicclient request for endpoint.
// will return the first one because the usage
// of the first one is greater the the usage of
// second one
39
5.6.
The Result of smagicclient:
yunwwang@linprog1.cs.fsu.edu:C++/Agent/MagicClient>smagicclient
response.endpoint: linprog2.cs.fsu.edu:18081
6 1 8
7 5 3
2 9 4
yunwwang@linprog1.cs.fsu.edu:C++/Agent/MagicClient>smagicclient 10
response.endpoint: linprog2.cs.fsu.edu:18081
49 37 25 13 1 99 87 75 63 51
60 48 36 24 12 10 98 86 74 62
61 59 47 35 23 11 9 97 85 73
72 70 58 46 34 22 20 8 96 84
83 71 69 57 45 33 21 19 7 95
94 82 80 68 56 44 32 30 18 6
5 93 81 79 67 55 43 31 29 17
16 4 92 90 78 66 54 42 40 28
27 15 3 91 89 77 65 53 41 39
38 26 14 2 100 88 76 64 52 50
40
6. Summary
Based on SOAP-XML technologies, a simple solution for Web Service was developed. It uses
P2P with the Discovery Server model and provides an interface to allow client to request a
service on a remote server without knowing where the server is located.
The project was implemented in C++. But the SOAP socket, which communicate with XML,
allows a C++ peer to exchange data with a peer written with other programming language if
invoked with the proper Stub compiler. The code is compiled under Linux with g++. With minor
changes, it can be compiled under Unix / Solaris / Win32.
The project is not limited by the simple example shown here. It can do more complicated P2P
computing and provides a better Web Service to the user. That is the Client can request not only
a simple service, like printing or getting a stock quote, but also a combination of some services,
like the appointment example shown before.
For future work, we will improve the performance, security and reliability of the system and
invoke a real database system for a large scale statistic usage.
41
7. Bibliography
[1] http://www.southweat.com
[2] http://www.passport.com
[3] http://www.w3.org/XML
[4] http://www.w3.org/TR/soap12-part1/
[5] http://www.w3.org/TR/wsdl
[6] http://www.uddi.org
[7] http://msdn.microsoft.com/vstudio/nextgen/default.asp
[8] http://www.sun.com/sunone
[9] http://www.jxta.org
[10] http://lucas.ucs.ed.ac.uk/xml-schema/
[11] R. van Engelen, K. Gallivan. The SOAP C/C++ Stub and Skeleton Compiler SDK for
Deploying Legacy Applications in SOAP Web Services and Peer-To-Peer Computing
Networks.
[12] http://www.napster.com/
[13] http://www.cs.fsu.edu/~engelen/soap.html/
42