Service Registry Policy Editing Interface for WS-Policy Validation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Users face challenges in creating WS-Policy and WS-Policy-Attach documents due to the high level of knowledge required to correctly specify the structure, often leading to errors in standard tools and text editors.

Innovation Solution

A service registry and repository system based on a triplestore database provides model-based user-interface editing capabilities, using software modeling techniques to support the creation of valid WS-Policy files by imposing constraints on user actions, allowing for the generation of conformant WS-Policy files.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If standard tools or text editors are used to create WS-Policy documents, then users have access to simple editing interfaces, but the documents often contain errors due to high knowledge requirements

Engineering Contradiction:
Improveease of policy document creationVSAvoidcorrectness of policy document structure
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent introduces an intermediary system (service registry and repository with model-based editing capabilities) between the user and the WS-Policy document creation process. This intermediary provides automated validation, constraint checking, and guidance to ensure documents conform to WS-Policy specifications without requiring users to be experts in the complex policy language syntax and structure.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system enables self-service by providing automated validation and error detection mechanisms that allow users to create correct WS-Policy documents independently. The model-based approach automatically checks document validity, identifies structural errors, and guides users through the creation process, eliminating the need for expert intervention or manual verification.

Inventive Principle:
Principle #25Self-service

2Reliability

If model-based user interface editing capabilities are implemented, then policy document correctness is improved, but system complexity increases

Engineering Contradiction:
Improveconformance of policy document to WS-Policy specificationVSAvoidcomplexity of service registry system
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies preliminary action by pre-defining WS-Policy specification models, validation rules, and constraint structures before the actual document creation process. These pre-configured models automatically guide users and validate documents in real-time, ensuring conformance without requiring complex runtime processing or manual intervention during document creation.

Inventive Principle:
Principle #10Preliminary action

3Manufacturing precision

If users are required to have high level of knowledge to create policy documents, then document structure accuracy improves, but user accessibility deteriorates

Engineering Contradiction:
Improveprecision of policy document structureVSAvoidaccessibility to different user skill levels
Core Design Contradiction:
Manufacturing precisionVSAdaptability or versatility

Solution Approach 1:

The system acts as an intermediary that translates complex WS-Policy structural requirements into user-friendly editing interfaces. The model-based approach automatically handles syntax validation, structural compliance, and specification conformance, allowing users with varying skill levels to create accurate policy documents without needing deep expertise in WS-Policy language requirements.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS8707171B2Service registry policy editing user interface
Publication Date: 2014.04.22 KMIZRA LLC
  • US8707171B2 patent drawing
  • US8707171B2 patent drawing
  • US8707171B2 patent drawing

AI summary

A selection of a service domain policy definition is received in a service repository. A service policy document is created from the service domain policy definition. At least one user change to the service policy document is received in accordance with the selected service domain policy definition. The service policy document is saved in the service repository.