Social Service Brokerage based on UDDI and Social Requirements

The choice of a suitable service provider is an important issue often overlooked in existing architectures. Current systems focus mostly on the service itself, paying little (if at all) attention to the service provider. In the Service Oriented Architecture (SOA), Universal Description, Discovery and Integration (UDDI) registries have been proposed as a way to publish and find information about available services. These registries have been criticized for not being completely trustworthy. In this paper, an enhancement of existing mechanisms for finding services is proposed. The concept of Social Service Broker addressing both service and social requirements is proposed. While UDDI registries still provide information about available services, methods from Social Network Analysis are proposed as a way to evaluate and rank the services proposed by a UDDI registry in social terms.

💡 Research Summary

The paper addresses a notable gap in Service‑Oriented Architecture (SOA) – the lack of mechanisms to evaluate service providers on social criteria such as trust, reputation, and prior collaboration. While Universal Description, Discovery and Integration (UDDI) registries are widely used to locate services that meet functional requirements, they suffer from decentralised management, outdated entries, and an absence of any social context. Consequently, a service consumer may discover a technically suitable service that is offered by an unreliable or defunct provider.

To remedy this, the authors propose the “Social Service Broker” (SSB), a hybrid intermediary that combines traditional UDDI‑based discovery with Social Network Analysis (SNA) driven evaluation of providers against explicit “social requirements”. A social requirement is a high‑level statement (e.g., “the provider must have a direct or two‑hop collaboration history with the consumer”) that is later translated into concrete SNA metrics such as direct‑edge existence, path length, centrality, or clustering coefficient.

The SSB workflow consists of seven steps:

1. The service consumer submits both functional and social requirements to the SSB.
2. The SSB forwards the functional part to a UDDI registry, which searches the Yellow and Green pages and returns a list of services that satisfy the technical criteria.
3. The registry also supplies White‑page metadata (basic contact information) for each candidate provider.
4. The SSB packages the candidate list together with the social requirements and sends them to an SNA server.
5. The SNA server evaluates each candidate against the translated metrics, producing a score or ranking that reflects how well the provider meets the social constraints.
6. The SSB returns the ranked list to the consumer.
7. The consumer selects the most appropriate provider and initiates the actual service request.

A concrete example illustrates the concept. Organization A needs a performance‑report writing service. UDDI returns three possible providers (F, H, J). The social requirement – “must be a direct partner of A or a partner of a direct partner” – eliminates J, leaving H (direct partner) and F (partner via G). Because H satisfies the requirement more directly, the SSB ranks H higher, enabling A to choose a socially trustworthy provider.

Key insights include:

• The necessity of a “translation” phase that maps abstract social requirements to measurable SNA indicators.
• The importance of maintaining an up‑to‑date collaboration graph, which may require dedicated trust databases or blockchain‑based ledgers to ensure data integrity and privacy.
• Potential scalability challenges, as SNA calculations over large enterprise networks can be computationally intensive.

The authors acknowledge several limitations. The paper remains at a conceptual level; it does not provide formal definitions of social metrics, nor does it address weight‑assignment for multiple criteria. Issues of data privacy, consent, and the overhead of continuously updating the social graph are left for future work.

Future research directions proposed include:

• Formalising the mapping between social requirements and SNA metrics, possibly using machine‑learning techniques to learn optimal weightings from historical transaction data.
• Developing efficient, incremental SNA algorithms that can handle dynamic, large‑scale enterprise networks.
• Integrating reputation systems, trust scores, or blockchain‑based provenance records to enrich the social graph.
• Conducting empirical validation through a prototype implementation within the IT‑SOA project, which involves construction companies in the Greater Poland region. The prototype will serve as a core component of the service‑oriented infrastructure, allowing the authors to assess the practical benefits and performance of the Social Service Broker in a real business environment.

In summary, the paper introduces a novel hybrid architecture that augments UDDI’s functional discovery with socially aware ranking via SNA. By doing so, it promises more reliable provider selection, aligning technical suitability with trustworthiness and collaborative history—an advancement that could be especially valuable in sectors where long‑term partnerships and reputation are critical.