Talk:Swordfish Documentation:Service Registry Admin Interface

From Eclipsepedia

Jump to: navigation, search

...

Contents

Use Cases

... simple Eclipse GUI ...

How simple does simple mean?

-> Initially a list view of objects is sufficient. Functions:

  • Upload/Import should be possible from Eclipse IDE and menu of admin interface.
  • Find/Get: Search-field and Button results in a simple list.
  • Download: resources can be selected from the list for download/export.
  • View (retreive): resource can be opened for viewing from the list. (Was already implemented)
  • Delete: resources can be selected from the list for download/export.

To execute an action on a selected resource from the list either context menu or a button can be provided.


  • upload/import ...
  • publish ...

It is debatable if it does make sense to make a difference between upload and publish. (See below)

...

  • download/export
  • get/retrieve

What's the difference between download and get? -> Removed the duplicate

...

Question: Do we need an operation: assignTo/relate for policies? To my understanding in UDDI this was covered through the annotation concept of UDDI itself.

No, if we reference he policy from within the WSDL document.

...

Artifacts: Initial:

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

You are requesting an almost complete registry. That's far to much for one sprint. -> For this sprint restriction to WSDL. Policy can be included into WSDL.

...

Administration operations shall be implemented as REST Service Operations.

When talking about REST you should talk about an interface rather than about operations.

...

Non functional aspects

Volume / Load aspects

Figures are missing for load and number of objects

-> For initial Solution 50 Objects, has to be extensible easily later.

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?

We should allow all combinations, for a first version we can have restrictions

  • Is it feasible to have the validation for relations between objects (should be a simple lookup on the resources which are referenced)

yes

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

The only access to the registry is HTTP

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

No, in a first step we should put it into the WSDL.

Separation between upload and publish

Discussion with Gerald Preissler:

the publish/unpublish feature is desirable, as otherwise the only way to disable/hide a Service is to delete it from the registry. This should be avoided. Hence the interface should be cept extensible for a later separation between functions.