1 Introduction

Web service is an emerging technology that allows interaction between applications in a programming language and platform-independent manner. World Wide Web Consortium (W3C) describes web service as a software system designed to allow interoperable machine-to-machine communication over the internet using XML, SOAP, WSDL and UDDI open standards. The key characteristic features of web service are, XML-based which allows platform independence, Loosely coupled that improves the system manageability and integrity, Coarse-grained services allow a proper level of information exchange, operate in both synchronous or asynchronous ways in the execution of services, handle transparent document exchange to support business incorporation, Interoperability allows the system to work on different technologies, Platform and language-independence keep no dependencies for programming language and operating system.

Web service architecture consists of three fundamental elements which communicate with each other as in Fig. 1. The basic three elements of web service computing architecture are the Service provider, service requestor and service registry. A service provider is responsible for creating a service, generating its service descriptions. A service consumer needs service and locates service descriptions that are published in one or more service registries. The service registry is responsible for promoting service descriptions published in it by service providers, and for making the service consumers find the required service from the collection of service descriptions published within it. Within the web service architecture, the service registry is a logically centralized directory of services. At present, there are three leading viewpoints on how a discovery service should be performed on the directory: as a registry, as an index, or as a peer-to-peer system.

Fig. 1
figure 1

Basic web service architecture

Full size image

Web service has three main components such as SOAP, WSDL and UDDI which have emerged as open standards for communication over the Internet. Simple Object Access Protocol (SOAP) is a platform-independent, XML-based communication protocol for information exchange between computers/applications over the internet. Web Services Description Language (WSDL) is an XML-based standard format for describing a web service. UDDI (Universal Description, Discovery, and Integration) is an XML-based specification designed for describing, publishing, and locating web services. Though web services have significant features, there are several technical challenges associated with them like centralized UDDI architecture, service availability, provider-consumer security, transaction integrity, and scalability. The issue taken into research in this work is the centralized UDDI architecture which means that the service registry is a single-point component for service publishing, selection [39, 41,42,43] and discovery operations [8, 9, 35, 40]. Thus the centralized UDDI (cUDDI) have the risk to be a single point of failure and network traffic, lack of efficient service description updation mechanism, performance degradation with an increase in service providers/consumers (scalability) and difficulty to maintain a large collection of service entries at a single place. To solve the various critical issues of cUDDI, a peer-to-peer structured UDDI will be an optimal solution. In this paper, we propose a distributed UDDI (dUDDI) framework which is a cooperative, loosely coupled P2P structured service provider model managed by a minimum loaded component called Service Provider Locator and Service Aggregator (SPLSA).

2 Related Works

There have been various strands of research in the literature to support a peer-to-peer-based framework for the UDDI registry. We present below an account of the various approaches for the decentralization of UDDI architecture performed by researchers.

Jo et al. [20] describe the various benefits of integrating web service and P2P technologies and design issues that arise in constructing the framework design. A concise design for three types of web service operation processes such as service publish, inquiry and invoke using sequence diagram [32]. Shadija et al. [18, 19] presented a technique to completely decentralize a service-oriented architecture using a self-organizing peer-to-peer network maintained by service providers and consumers [28]. In [2], a novel P2P-based UDDI (PDUS) approach is presented using distributed Register Center Nodes (RCNs) in which services are published. Libing et al. [31] claim that the centralized UDDI model leads to performance degradation because too many services are being registered and queried. They proposed an interoperable model for distributed UDDI with three server types namely root, super domain and normal server which are managed hierarchically. Though it discussed little on the service publish operation but service discovery, security, scalability and reliability issues are left untouched.

Wang et al. [3] proposed a mechanism for web service publication, discovery and invocation with the scheme of a P2P network using super/group peer without a dedicated “central server”. Zongxia et al. [4] proposed an active and distributed registry, Ad-UDDI, the service information is distributed among multiple registries to avoid traffic bottlenecks in one public UDDI. This Ad-UDDI implements a three-layered hierarchical model of distributed service registry which again has the risk of single point crash on top layers and also propagation of service update information within the system is more complicated. In [9], authors claim that decentralizing UDDI registries leads to another level of complexity on how to effectively discover the services across the distributed registries. In [16] Al-masri et al. depict that the ability to discover Web services of interest then across multiple UBRs becomes a major challenge. But the architecture presented lacks an effective provider-consumer communication structure and crawling all the available registries is virtually impossible to accomplish. In [33], authors proposed a new structured P2P overlay network infrastructure designed for web services discovery operation which supports two ranges of queries [17]. In [39], Wang et al. proposed QoS-Aware Service Discovery and Selection technique for a cloud environment based on an optimization algorithm.

In [2, 3] and [20], only a theoretical description of the proposed system has been discussed but experimentation and analysis, which must justify its effectiveness, are left for future research. There are other remarkable contributions to peer-to-peer based web service architecture [38] have been proposed such as pService [5, 6], semantic web service system [1, 14, 30] hash table-based super peer [10], broker-based design [11, 21], agent-based organization [12, 13, 22], Bio-Inspired models [34, 36, 37, 39, 41] and semantic-based peer classification [7, 15, 41]. Each technique has its pros and cons, but none of the work can be claimed as the most thriving architecture based on the critical performance criteria. In the work [23], a distributed UDDI framework has been developed to address the problems of the existing centralized UDDI model. The framework followed the recent release specification of UDDI v3 and focused on minimizing unequal access to services, poor processing performance and vulnerability of single point of failure. In addition, service publication and service discovery have been improved and the strong practicality of the distributed UDDI method was validated. In [24], the authors claim that the centralized UDDI suffers from a single-point failure issue and high maintenance costs. To cope with these issues, the researcher proposed a novel framework based on a catalogue of mobile agents and metadata for web service discovery. The proposed model works based on the user profile to search and find a suitable web service, satisfying consumer requests, in less time and taking into account the QoS properties [25, 29].

Baresi et al. [26] claim that the service registry in SOA concepts is not very effective due to problems of safety and governance. To overcome the issue, a distributed implantation of registry DREAM (Distributed Registry by ExAMple) is proposed which is a public / subscribed solution to combine existing, separate registries, along with a corresponding approach to ease the publishing and discovery of services. The authors proposed a system of chord-based semantic service discovery framework with QoS consideration [25]. In the model, QoS-related criteria are placed in OWL-S to describe services and adopt chord-based distributed storage. Also proposed an OWL-QoS-based matching algorithm to discover services. The findings of the experiment demonstrated that the method proposed increased the reliability and accuracy of the discovery of web services. In [27], a novel architecture is proposed based on the mobile agent, and user profile for web services discovery to mitigate the search space and improve the relevant service retrieval.

Observations from the study: The registry type of directory holds fast retrieval requested service but it suffers single-point failure that affects the reliability of the system, inactive service references and complex ownership constraints. On the contrary, the peer-to-peer type of directory holds decentralization, reliability against single point failure and active & updated service pointers but suffers from problems such as high response delay, high performance-cost, path propagation of request (a peer may receive the same service request many times), inefficient service search, overload network with service request message and no guarantee that a request will spread across the entire network. Thus, these two types of directories should be merged to have the advantages and also limitations of one type will be mutually surmounted by the other. A novel P2P-based UDDI architecture is required which should have the following features, decentralized registry, no single point of failure, effective method for service publishing, distribution and discovery, retrieved service will be active and updated and improved system reliability and scalability.

3 Proposed System

3.1 The dUDDI Architecture

The proposed distributed UDDI (dUDDI) architecture is a combination of the registry and peer-to-peer types of service registries. The service providers and consumers are arranged in a P2P fashion and the dUDDI system contains a collection of minimum-loaded SPLSA which acts as a local service directory. Figure 2. shows the distributed structure for the web service paradigm using dUDDI architecture.

Fig. 2
figure 2

Distributed structure for web service paradigm using DUDDI

Full size image

It is much essential to understand the relationships among various entities involved in the proposed web service paradigm using dUDDI architecture. Figure 3 depicts the complete web service-centred relationship among the various components in the dUDDI architecture. The distributed UDDI architecture proposed in the research consists of three elements, Service provider, Service consumer and dUDDI system. Figure 4 illustrates the architecture of dUDDI with its elements and the interaction among them.

Fig. 3
figure 3

Service centered relationship diagram for various components

Full size image
Fig. 4
figure 4

Distributed UDDI architecture

Full size image

The web service computing environment and operations can be represented as,

$$WS_{opr} = \left\{ {P, \, D} \right\}$$

where, WSopr refers to the web service computing model operations, P refers to the publish operation and it can be represented as,

$$P = \left\{ {T_{s} , \, I_{s} , \, W_{s} } \right\}$$

where, Ts represents the title/name of the web service, Is represents the service information/description, and Ws represents the WSDL representation of Is.

D refers to the discovery operation and is represented as,

$$D = \left\{ {R_{F} , \, R_{NF} } \right\}$$

where, RF represents the functional requirements or keywords, and RNF represents the non-functional requirements or QoS measures.

3.1.1 Service Consumer

A web service consumer is the actual user of a service. From the perspective of an application, a service consumer can be a service or application or other types of software module that requests a web service. The module triggers the process of discovering the service from the registry, binding to the service transport details, and executing the service. In the proposed model, consumers are the peers who, on demand, request its nearest SPLSA to retrieve the service based on the service requirements embedded in the SOAP message. As a response, the consumer receives a reply SOAP message which contains the graded services that are appropriate to the service requirement specifications. The response also comprises details required to communicate to the provider, such as the addressing of the provider corresponding to the service, service identification number, service versioning, service updation, binding and transport information. Using the details acquired from the SPLSA, the consumer communicates with the service provider which suits its requirements.

3.1.2 Service Provider

Service providers are the nodes that store the service code/ component they provide to their requested consumers. The service provider maintains a catalogue of various services categorized based on different versioning. Though the service providers are organized in a P2P fashion, they are cooperatively structured in such a way that each provider has a linkage to other providers who provide a similar type of service. The linkage details among providers are managed by SPLSA at the time of service registration by the provider. Each provider has a Link to Providers (LtP) module which holds the details of the providers it is linked with. To publish a service, the provider generates a Web Service Description (WSD) details of the service and communicates the same as a SOAP message to its nearest SPLSA. As a response, the provider will receive a unique service identification number (Sid) for the service it has requested to publish. In future, any further operation on the service like updation, versioning or discovery is carried out using the Sid assigned to the service. The structure followed to preserve linkage among providers is a Doubly Linked List (DLL). DLL structure is preferred because of the following benefits,

  • To traverse ‘n’ service providers, only ‘n’ messages are needed even in the worst case.

  • The structure can fairly share the load between the peers and reduce bottlenecks.

  • The structure has its dual-way organization which helps to improve the robustness and to know which peers have already visited or not.

  • Each provider peer forward the service search requests to its linked providers so that all the similar service providers are made to respond to the request.

When a service provider publishes a service, SPLSA will search for a similar type of service in its Service Locator Start List (SLSL). If it found any similar service, it makes any of the existing service providers point to the current publishing provider with its DLL structure constraints. Otherwise, a new record is created in SLSL and the current provider’s details are stored as the start node.

Services retrieved from the DUDDI using QoS matchmaking would be represented as a matrix (Sij) of services as,

$$S_{ij} = \left[ {\begin{array}{*{20}l} {q_{11} } \hfill & {q_{12} } \hfill & {q_{13} } \hfill & \ldots \hfill & {q_{1j} } \hfill \\ {q_{21} } \hfill & {q_{22} } \hfill & {q_{23} } \hfill & \ldots \hfill & {q_{2j} } \hfill \\ \vdots \hfill & \vdots \hfill & {} \hfill & {} \hfill & {} \hfill \\ \vdots \hfill & \vdots \hfill & {} \hfill & {} \hfill & {} \hfill \\ {q_{i1} } \hfill & {q_{i2} } \hfill & {q_{i3} } \hfill & \ldots \hfill & {q_{ij} } \hfill \\ \end{array} } \right]$$

where, ‘i’ refers to the total number of services retrieved from the DUDDI, ‘ij’ refers to the jth QoS parameter of the ith service and ‘qij’ refers to the value of the jth QoS parameter of the ith service.

SPLSA can either be public or private. A public SPLSA, which can be managed by an open group, can register and hold the service information of any providers who are agreeable to publish. Private SPLSA is maintained by any organization which is responsible for the services publishing and maintenance of the published services. Private SPLSA can be used as a service directory within an organization or as commercial purpose service access. A single commercial organization may maintain a collection of SPLSAs, which works mutually, and service can be published in more than one public SPLSA.

3.1.3 dUDDI System

The dUDDI system acts as an intermediate between the service provider and the consumer to publish and discover the service. The dUDDI system consists of a collection of dedicated peers called Service Provider Locator and Service Aggregator (SPLSAs) which perform the task accomplished by the cUDDI component, with minimum traffic, in a distributed manner. Each SPLSA can operate as a standalone registry or a part of a group registry where coordination among the participant SPLSAs is a critical issue in service publishing and discovery. SLSL of a SPLSA maintains the essential information about the services that are published which is used to locate the service provider on service discovery operation. In SPLSA, published services are segregated using search keywords, and service segregation based on domain, ontology and platform.

4 Components of dUDDI Architecture

4.1 Service Consumer

In general, Service consumers are persons or software entities that discover and invoke the service published by the providers. In dUDDI architecture, important functions of service consumers are,

  • perform user authentication and session management

  • acquire service request specifications, wrap up into a SOAP message and forward to SPLSA

  • display the service search response received from SPLSA

  • Error management between the user and SPLSA

Service consumer building blocks, shown in Fig. 5, are,

Fig. 5
figure 5

Internal components of service consumer in dUDDI architecture

Full size image

4.1.1 Authentication Module

This module is responsible for conversion with SPLSA for user authentication and session management.

4.1.2 Service Request Wrapper

The request wrapper is responsible to retrieve the required service specification details from the user and forward the request in SOAP format to SPLSA.

4.1.3 Service Response

SPLSA will respond to the user request with complete details about the providers whose service specification matches the user’s requirements. This module is responsible to interact with the user based on the response received.

4.2 SPLSA

SPLSA is an intermediate between the service requester and the provider. It performs the following tasks,

  • Receive the service request from the consumer.

  • Session and Authorization management.

  • Assigning request ID and message encryption policies.

  • Locate the providers who provide the service requested and multicast the request.

  • Aggregate the service responses received from different providers based on request ID.

  • Reply to the consumer with the consolidated service responses as a single message.

  • Error management between the service requester and provider.

SPLSA building blocks, shown in Fig. 6, are,

Fig. 6
figure 6

Internal components of service SPLSA in dUDDI architecture

Full size image

4.2.1 Service Description Grabber

This module performs pooling at a specific address at which the consumer sends the request either through the browser or application and assigns a service Identification (sID) number. The request is received in the SOAP message format extracts the service description or search keyword part of the message and forwards it to the next module.

4.2.2 Authentication and Session management

This module performs authentication of consumers with credentials (say username and password). Authentication is performed using the user credential database which is updated while the user registers on SPLSA. If the authentication fails then an Error message is sent to the service requested consumer otherwise a fresh session with unique Session identification (seID) is created and seID is sent to the user. This module plays an essential role in the security and operational integrity aspects of the model.

4.2.3 Provider Start Link Locator (PSLL)

This module performs the task to identify the service providers who offer the service that matches with service description or search keywords extracted from the request message. A sub-module, Service Locator Start List (SLSL) is a database used to link the providers offering similar types of services. SLSL consist of fields such as service ID, service description and Start Link List (SLL) as shown in Fig. 7. SLL contains the link (probably the IP and port addresses of providers) to the first few service providers matching the requested service and request message is forwarded to them. The cache module store the frequently accessed service details to speed up the repeated and related requests. This module also works with data consistency techniques to evade obsolete data responses.

Fig. 7
figure 7

Service locator start list structure

Full size image

4.2.4 Aggregator and Ranking

This module receives the service reply from the various service providers and ranks the result services (on demand) based on the matching with the search criteria. It consolidates the received or ranked services into a single message and forwards it to the service requester.

4.3 Service Provider

The service provider is any host that implements a web service and makes it available on the Internet. The service provider module, shown in Fig. 8, consists of the following blocks,

Fig. 8
figure 8

Internal components of service provider in dUDDI architecture

Full size image

4.3.1 ID Repetition Check

When the provider receives a request from SPLSA, this module checks whether this service request is already received to avoid repeated processing of the same request.

4.3.2 Parse through Service Description

The request is received in the SOAP message format and this module extracts the service description or search keyword part of the message. The service description is parsed to extract the keywords and send it to the service selection module of the provider.

4.3.3 Service Selection

This module performs the task to prefer the service that suits the service requested based on the parsed keywords.

4.3.4 Forwarding Service Information

This module creates a SOAP message which is embedded with details of providers and the service chosen for requested criteria. This SOAP message is forwarded to SPLSA to promote it to the consumer.

4.3.5 Link to other Providers

This module has links for other service providers who offer a service similar to that of the current service request.

4.3.6 Error message management

This module takes control of all the error notifications during the communication between the SPLSA and other providers to offer the integrity of the search procedure and service selection.

5 Operations of dUDDI Architecture

The process of working on the two important UDDI operations namely service publishing and discovery are discussed in this section.

5.1 Web Service Publishing

Publishing a Web service means enabling a Web service consumer to locate the service description and instructing the consumer on how they should interact with the Web service. The service publish process takes place, as shown in Fig. 9, with the following steps,

Fig. 9
figure 9

Web service publish operation in dUDDI architecture

Full size image

Step 1 The publisher who wants to publish a service need to provide the admin credentials which should be registered with the SPLSA.

Step 2 SPLSA receives the request SOAP message and authenticates it for a genuine user. If authentication fails an error message is replied to the requestor otherwise a new session is created with a unique ID. This session is maintained till the whole service publish process completes.

Step 3 SPLSA assigns an ID to the request and extracts the service description from the request SOAP message received. The extracted service description is parsed to extract the keywords.

Step 4 PSLL module of SPLSA use the extracted keywords to search against the keywords column of SLSL. If no match is found, then the extracted keywords are generalized and the search operation is repeated.

Step 5 If a keyword match is found in SLSL, then the service providers’ details (IP and port addresses) are retrieved from the SLL column corresponding to the matched keyword column.

Step 6 SPLSA create SOAP message by replicating the received request message embed service ID and message hop count (based on several providers index since only one hop is required for one provider), then forward it to the service providers retrieved.

5.2 Web Service Discovery

Service Discovery is the process of identifying the service offered by the providers that fulfil the requirements of the consumer. Service discovery takes place, as shown in Fig. 10, with the following steps,

Fig. 10
figure 10

Web service discovery operation in dUDDI architecture

Full size image

Step 1 The service consumer creates a SOAP message with the required service description and forwards it to SPLSA through a browser or application.

Step 2 SPLSA receives the request SOAP message and authenticates it for the true user. If authentication fails an error message is replied to the requestor otherwise a new session is created with a unique ID. This session is maintained till the whole discovery process completes.

Step 3 SPLSA assigns an ID to the request and extracts the service description from the request SOAP message received. The extracted service description is parsed to extort the keywords.

Step 4 PSLL module of SPLSA use the extracted keywords to search against the keywords column of SLSL. If no match is found, then the extracted keywords are generalized and the search operation is repeated.

Step 5 If a keyword match is found in SLSL, then the service providers’ details (IP and port addresses) are retrieved from the SLL column corresponding to the matched keyword column.

Step 6 SPLSA create SOAP message by replicating the received request message embed service ID and message hop count (based on the number of providers index), then forward it to the service providers retrieved.

Step 7 The service provider receives the SOAP formatted service request message from SPLSA and checks whether the same service request ID is already received or not to avoid repeated processing of the same request.

Step 8 The provider extracts the keyword from the request message and selects a service that matches the consumer’s requirement. Then, the provider creates a response SOAP message and includes the details of matched service (like URL) and provider constraints. This response message is forwarded to SPLSA from where it received the request message.

Step 9 After sending the response message, the Link to Providers (LtP) module identifies the other providers which linked with the current provider for the requested service and forwards the request message to them. This message is forwarded to all the linked providers (both Parent Provider Link and Child Provider Links) except where it received the request message.

Step 10 From Step 7 to Step 9 is repeated till the provider’s index or hop count embedded with the message expires.

Step 11 SPLSA receives the reply from the different service providers and ranks them based on the keywords on the request and the response. These ranked replies are consolidated into a single SOAP-formatted response message and forwarded to the service requester.

In the process of service discovery, conversations among the various entities are carried out in SOAP message format.

6 Experimentation and Result Analyses

6.1 Experimental Setup

To evaluate the proposed model, the web service selection operation has been accomplished on the services which are retrieved from the repository on the user-preferred QoS parameter ranges. The system used for implementation purposes is Intel i3 processor with a 16 GB RAM machine connected to a 100 MB/s Ethernet, Windows 10 and IDE Eclipse to retrieve the services. And the optimization process was done in MATLAB for the effective use of the web services.

In the service oriented architecture, a web service composed of a collection of measures corresponds to the QoS element of the service. The service set S be the collection of ‘u’ services from the UDDI and each service consists of a ‘q’ number of QoS factors,

$$S = \left\{ {s_{1,} s_{{2,{ }}} { }.{ }.{ }.{ }.{ }.{ }s_{u} } \right\}$$
$$S_{k} = \left\{ {Q_{1,} Q_{{2,{ }}} Q_{3,} Q_{4} \ldots ,Q_{q} } \right\}$$

where, u is the total number of services in the UDDI, q is the total number of QoS parameters for the service k in S.

In the current scenario, there is no standard web service discovery testing methodology and so, a list of real-time web service provider are gathered and registered with the UDDI. A testbed has been generated consisting of 1000 web services of various domains and services are manually divided into domains such as Airlines, Tourist, Automobile, Postal, Banking, Bioinformatics, News, Conversion, Search, Weather, Dictionary, Education, Employment, Entertainment, Financial and Social Networking. Each domain will have 21 QoS parameters like Penalty (P), Incentives (I), Service Reputation (SR), Service Provider Reputation (SPR), Response Time (RT), Throughput (T), Controllability (CN), Availability (A), Accessability (AC), Non-Repudiation (NR), Successability (SU), Standard Adoptability (SA), Standard Conformability (SC), Reliability (R), Transaction Integrity (TI), Informability (IN), Authentication (AT), Authorization (AZ), Collaborability (C)and Privacy (PR).

To improve the precision of the experiments, the scenario considered for the experiments consists of a collection of different classes as in Table 1. Each class contains a different combination of QoS factors deliberated for the performance evaluation. Based on the type of class used for experiments, service requestors are allowed to specify the range of QoS factors corresponding to the class used for the particular scenario.

Table 1 List of various classes and their QoS factors combination
Full size table

6.2 Assessment Criteria

The following are some of the performance factors (adapted from [24]) used to evaluate the performance of the proposed web service model, as the evaluation metrics of web service retrieval are similar to the information retrieval scheme. The relevance of a retrieved web service can be measured based on the factors like relatedness, topicality, beneficiality and utility. In the proposed model, we have considered relevance in two directions topical and user utility relevance. The relevance of the service based on the topical relevance is determined using the keywords provided by the consumer in the service search query and the service domain. Relevance measurement based on the user utility is performed based on different QoS parameters considered in the experiments.

6.2.1 Precision (P)

Precision can be referred to as the part of discovered web services that are appropriate to the user’s requirements. The formula for the same can be expressed as,

$$Precision = \frac{{\left| {S_{Relevant} } \right| \cap \left| {S_{Retrieved} } \right|}}{{\left| {S_{Retrieved} } \right|}}$$
(6.1)

where, |SRelevant| is the total number of services that are relevant to the request. |SRetrieved| is the total number of services that are retrieved.

6.2.2 Recall (R)

The recall is the number of relevant services that are fetched to the user’s requirements. The formula for the same can be expressed as,

$$Recall = \frac{{\left| {S_{Relevant} } \right| \cap \left| {S_{Retrieved} } \right|}}{{\left| {S_{Relevant} } \right|}}$$
(6.2)

where, |SRelevant| is the total number of services that are relevant to the request. |SRetrieved| is the total number of services that are retrieved.

6.2.3 F-Measure

F-measure can be defined as the harmonic mean of precision and recall. The formula for the same can be expressed as,

$$F - Measure = \frac{2*Precision*Recall}{{Precision + Recall}}$$
(6.3)

6.3 Result Analysis

In this section, the efficacy of the proposed dUDDI architecture along with the recent and best working decentralized UDDI models referred to in [23, 24] and [27] under similar experimental setups is discussed concerning the appropriate set of performance criteria as discussed in Sect. 6.2. Table 2 illustrates the performance of different decentralized UDDI models on the capability of service retrieval from the UDDIs under various scenarios considered for the experiments. This experimental result is rudimentary based on which the results for various performance factors are measured and justified.

Table 2 Performance in service retrieval of different decentralized UDDI models
Full size table

6.3.1 Precision

The evaluation based on the factor precision reveals the ability of the decentralized UDDI models on retrieving the collection of services that are exactly requested by the service requestors to the total number of services retrieved from the UDDI considering the demand QoS factors. The experimental results for the various techniques w.r.t the precision factor and the improvement rate is shown in Table 3.

Table 3 Experimental results for the various decentralized UDDI models w.r.t the Precision factor
Full size table

In the perception of the precision assessment factor, the proposed dUDDI model performs better than the various existing decentralized UDDI models considered for evaluation. It can be observed that the proposed dUDDI model obtained more than 90% precision achieved up to class VII of QoS factors regardless of the number of services considered in the UDDI. On the other hand, the precision value of [24, 27], and [23] drops below the 90% mark at the class IV, II and I of QoS combinations respectively. In the case of the proposed dUDDI model, the least precision value obtained is 82.22% for 100 services with Class X of QoS factors combination which stands much superior to the next better 71.43% for the same scenario setup. The precision-based performance analyses on different UDDI models are shown in Fig. 11 which illustrates that the proposed model outperforms the recent and the best working decentralized UDDI models regardless of the type of QoS combination class and the number of services in the concerned UDDI. The three parts of Fig. 11a, b and c represents the precision value of the models with 100, 500 and 1000 services in the UDDI respectively.

Fig. 11
figure 11

Precision based performance analyses on different decentralized UDDI Models

Full size image

To demonstrate the significance of the proposed model, the improvement in the performance of the proposed model over the existing techniques has been tabulated in Table 3. From the table, it can be evidenced that the proposed model shows significant improvement w.r.t the existing models. At maximum, the proposed model obtained 51.35% over the model in [23] for Class V with 100 services, 53.06% over the model in [27] for Class X with 100 services, and 25.56% over the model in [24] for the Class V with 100 services. This justifies that the proposed model shows a substantial improvement in the performance of the web service retrieval over the existing models despite the size of the UDDI and the complex combination of the QoS factors provided for the service requestors. Precision-based performance improvement rate on different models is shown in Fig. 12. The three parts of the Fig. 12a, b and c represent the precision performance improvement rate of the model with 100, 500 and 1000 services in the decentralized UDDI respectively.

Fig. 12
figure 12

Precision based performance improvement rate on different decentralized UDDI Models

Full size image

6.3.2 Recall (R)

The experimental results for the various techniques w.r.t the Recall factor and the improvement rate are shown in Table 4. From Table 4, it can be perceived that the proposed model achieved 100% of recall for 20 sets of experiments whereas the existing models in [24, 27] and [23] were able to obtain only 2, 1, and 0 sets of experiments respectively. The least recall value obtained for the proposed model is 94.87% for 100 services with Class X of QoS factors combination and the next best-least recall value registered by the [24] model is 89.74 for 100 services with Class X. Thus, based on the observation of the recall measures, the proposed dUDDI model outperforms the various existing decentralized UDDI models considered for evaluation regardless of the type of QoS combination class and the number of services in the concerned UDDI and the same has been shown in the Fig. 13. The three parts of the Fig. 13a, b and c represents the recall performance of the models with 100, 500 and 100 number of services in the UDDI respectively.

Table 4 Experimental results for the various decentralized UDDI techniques w.r.t the Recall factor
Full size table
Fig. 13
figure 13

Recall based performance analyses on different decentralized UDDI Models

Full size image

Table 4 also exemplifies the performance improvement rate of the proposed model over the existing techniques. From the table, it can be justified that the proposed model shows a significant improvement rate w.r.t the best working decentralized UDDI models. At maximum, the proposed model obtained 33.33% over the [23] for Class X with 100 services, 25.00% over the [27] for Class X with 100 services, and 8.62% over the [24] for Class VII with 100 services. The recall-based performance improvement rate on the proposed model w.r.t the different models is shown in Fig. 14. The three parts of Fig. 14a, b and c represents the recall performance improvement rate of the models with 100, 500 and 100 number of services in the UDDI respectively. From the figure, it can be identified that the proposed model shows a significant improvement in the performance of the relevant web service retrieval over the existing models despite the size of the UDDI and the complex combination of the QoS factors provided for the service requestors.

Fig. 14
figure 14

Recall based performance improvement rate on different decentralized UDDI Models

Full size image

6.3.3 F-Measure

The experimental results for the various techniques w.r.t the F-measure factor and the improvement rate are shown in Table 5. The table illustrates that the proposed model achieved greater than 90% of the f-measure value for all the classes of QoS factors regardless of the number of services considered in the UDDI. On the other hand, the f-measure value of [24, 27] and [23] drops below the 90% mark at the class IV, II and I of QoS combinations respectively. The least f-measure value obtained for the proposed model is 90.10% for 100 services with Class X of QoS factors combination and the next best-least f-measure value registered by the [24] model is 79.21% for 100 services with Class IX. Thus, it can be claimed that the proposed dUDDI model overtakes the various existing decentralized UDDI models considered for evaluation irrespective of the type of QoS combination class and the same has been shown in Fig. 15. The three parts of Fig. 15a, b and c represents the f-measure performance of the models with 100, 500 and 100 number of services in the UDDI respectively.

Table 5 Experimental results for the various decentralized UDDI techniques w.r.t the F-Measure factor
Full size table
Fig. 15
figure 15

F-Measure based performance analyses on different decentralized UDDI Models

Full size image

From Table 4, it can also be vindicated that the proposed model shows a significant improvement rate w.r.t the models considered for evaluation. At maximum, the proposed model obtained 44.1% over the [23] for Class IX with 100 services, 40.63% over the [27] for Class IX with 100 services, and 15.48% over the [24] for Class VIII with 100 services. The f-measure-based performance improvement rate on the proposed model w.r.t the different other models is shown in Fig. 16. The three parts of the Fig. 16a, b and c represents the f-measure performance improvement rate of the models with 100, 500 and 1000 services in the UDDI respectively. From the figure, it can be identified that the proposed model shows a significant improvement in the performance of the web service retrieval over the existing models despite the size of the UDDI and the complex combination of the QoS factors provided for the service requestors.

Fig. 16
figure 16

F-Measure based performance improvement rate on different decentralized UDDI Models

Full size image

7 Summary

In summary, an experiment was designed and carried out to examine the proposed dUDDI model for various performance attributes. The preliminary results suggest that the proposed model outperforms the existing and best-working decentralized UDDI models concerning the performance factors considered. The interesting fact to be noted is that the proposed model shows extraordinary performance with an increase in the number of services deployed in the UDDI. This significant characteristic enables the proposed model suitable for the large-scale web service environment to adopt the model for high-level performance enhancements.

8 Conclusion

A complete study of web services and the various issues involved in emerging technology has been discussed. One of the important issues is centralized UDDI architecture, which leads single point of failure and traffic overhead, which is considered in this work. In this paper, we presented a distributed UDDI (dUDDI) architecture and also discussed various internal components of dUDDI elements. We also presented an efficient algorithm for web service publishing and discovery operations in the dUDDI architecture. The proposed dUDDI model is evaluated with the best-in-class decentralized UDDI models by considering different conditions like the registry size, QoS factors and discovery of the relevant services based on user request. A testbed has been generated consisting of 1000 web services of various domains and services are manually divided into 21 domains with different QoS requirement combinations. The experimentation results justify that the proposed model outperforms the existing decentralized UDDI models in terms of precision, recall and f-measure factors.