Swordfish Documentation:Service Registry Admin Interface

{{#eclipseproject:rt.swordfish}} Provide Feedback to this Feature on th Talk Page.

Description

An Administration Interface shall be provided for the Swordfish Service Registry

Current Problem / Pain

Currently Registry artifacts need to be handled manually.

Advantages/Business Case

An Administration interface is required for ease of use and as a basics for a registry providing governance for a SOA environment.

Use Cases

There shall be an Administration Tool with a simple Eclipse GUI which shall provide the following operations for all defined service artifacts:

• upload/import (stores the resource in the registry and publish them)
• get/retrieve (is already implemented). This function also should allow to download/export multiple resources.
• search/find (based on strings contained in the namespace or the name)
• delete

Artifacts: Initial:

• WSDL
• WS-Policy (Optional)(corresponds to SOPERA Operation Policy)

It shall be later extensible for:

• Schema (Later)
• Service Description
• Service Provider Descriptions
• Participant Policies

Administration operations shall be implemented as REST Service Operations. All operations shall be accessible through a GUI and through a programmatic interface.

Conditions of satisfaction

• Feature is complete: Start/RunControl and Documentation Criteria shall be fulfilled. Examples are not required for this feature.
• Demonstrate all operations listed above
• Demonstrate a failed retrieval of a WSDL
• Demonstrate a failed publish because of wrong references. Fix the reference, upload and publish successfully.
• Demonstrate a lookup of a published service
• Show successful integration test results including negative tests for the programmatic interface.

Limitations

Validation may be restricted to correct references from WSDL to Schema, and WSDL to WS-Policy.
The validation for correctness of WSDL and policies can be included in a later step but implementation has to be open to integrate schema validations easily also.
Feature completeness: Installation as Eclipse Feature and deployment can be added later.

Non functional aspects

Volume / Load aspects

The implementation may not support in the initial implementation, but has to be open to Support mass operations. For the initial version it should be easy to work with around 50 resources. It has to be extensible for next version.

Security aspects

Authentication. Authentication concept has to be kept open for a client concept(German: Mandant). Authorization on operation level. Question: Object level desired?

Ease of Use

A simple Eclipse GUI shall be provided for Administration.

Open Questions

• The SOPERA Artifacts split the WSDL in 2 files Service Description and Service Provider Description. In principle it could also be useful to have 3 Levels: 1. Message + Porttype, 2. Binding, 3. Port (Endpoint). Is this useful? Necessary? Would we need to keep it open to extend it correspondingly later?
• Is it feasible to have the validation for relations between objects (should be a simple lookup on the resources which are referenced)
• To discuss: Is it possible and useful to provide programmatic access to the Service Registry administration operation on provider side directly or do we need a client side facade interface?
• How Simple could the GUI be? Would we be satisfied with a simple list display of Items separated by artifact type and default sorted alphabetically? Would we an ID which can be kept short instead of displaying the full URI (This would mean a table instead of a list) be useful?
• Do we need an operation: assignTo/relate for policies? To my understanding in UDDI this was covered through the annotation concept of UDDI itself. Easiest would be that within the WSDL the URI of the WS-Policy to be used can be referenced directly.

See Talk Page for discussion and answers.

---

Return to Eclipse Swordfish Swordfish Product Backlog

Swordfish Wiki Home