Preface - Florida State University



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

Table of Contents

1. Project Goals and Accomplishments 5

2. Introduction 6

2.1. Web Services 6

2.2. B2B (Business-to-Business) 7

2.3. SOAP (Simple Object Access Protocol) 8

2.4. WSDL (Web Service Description Language) [5][11] 9

2.5. UDDI (Universal Description, Discovery, and Integration) [6] 10

2.6. P2P (Peer-to-Peer) 11

2.7. Industry Support for Web Service and P2P 14

3. Design of the P2P Computing Infrastructure with SOAP 16

3.1. Application Feature 20

4. Implementation of the P2P Infrastructure with SOAP 21

4.1. The gSOAP Stub and Skeleton Compiler for C and C++ 21

4.2. gSOAP Example 21

4.3. Types and Data Structures used by the P2P Agents 22

4.4. Client 24

4.5. Client Agent 25

4.6. Service Agent 30

4.7. Service Provider 33

4.8. Statistics Provider 34

5. Results 36

5.1. Parts of the Code of smagicclient.cpp 36

5.2. The Result of Service Agent: 36

5.3. The Result from Service Provider: 37

5.4. The Result of Statistic Provider: 38

5.5. The Result of Client Agent: 38

5.6. The Result of smagicclient: 40

6. Summary 41

7. Bibliography 42

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.

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.

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

Introduction

This section introduces Web Services, SOAP, WSDL, UDDI, B2B, and P2P computing.

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 XML-based 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.

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

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 firewall-friendly 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.

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.

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.

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.

[pic]

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.

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.

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

[pic]

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 single-point-of-failure problem.

[pic]

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.

[pic]

Fig. 4 P2P with a Discover and Content Server

7 Industry Support for Web Service and P2P

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.

[pic]

Fig. 5 Microsoft .NET Web Services

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.

[pic]

Fig. 6 Sun ONE Web Services

3 Sun JXTA

Sun also has a project named JXTA for P2P computing. JXTA is a set of open, generalized peer-to-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.

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.

• 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

[pic]

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 re-send 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 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 // time stamp of ws file

s_statUrl: linprog2.cs.fsu.edu:18400/statms.txt

i_usage: 6 // 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 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.

2 Application Feature

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.

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 Query

Client Agent get request from Client. Find the appropriate service in the database and return the information to the Client.

4 Sharing

A Service Agent shares its information with other Service Agents. A site shares its services with other sites.

Implementation of the P2P Infrastructure with SOAP

In this section the implementation of the P2P infrastructure with SOAP is discussed.

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++.

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”, “”,

{“SOAP_ENC”, “”},

{“xsi”, “”},

{“xsd”, “ ”},

{“ns”, “urn:magic”};

{NULL, NULL}

}

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.

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.

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.

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 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:

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.

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.

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.

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.

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()

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 );

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.

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.

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.

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 );

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.

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:

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 endpoint-time 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.

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.

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.

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.

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.

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.

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.

Results

1 Parts of the Code of smagicclient.cpp

int main(int argc, char **argv)

{

int r;

if (argc hostw

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()

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

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()

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

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

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

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.

Bibliography

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

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

[13]

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

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download