Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Bugzilla 165556

Revision as of 07:57, 12 December 2006 by Unnamed Poltroon (Talk)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Discuss this feature

TPTP feature: 165556

Author: Krishna C Shastry
email: krshastr@in.ibm.com
Committer email: bsubram@us.ibm.com(Balan Subramanian)
Last updated:


Rough workload estimate for design/code/test in person weeks:

ProcessSizing
Design1
Code3
Test1
Documentation0.5
Total 5.5

Rough workload estimate for build and infrastructure in person days: 0.0


Requirement summary

A Service Group is a collection of WS-Resources, each represented as a WS-ServiceGroupEntry, which follow some constraints (possibly none) defined by the Service Group. As part of the definition of a SG, the user must be able to define the membership constraint rules using the service group editor.

User interactions

User interface

TBD

Extension points

Code interfaces

Design summary

To create New Service Group Definition an option must be made available under Management Instrumentation in the New > Other wizard selection dialog. In the over view page, a new section must be provided for editing Membership content rules.

  • 1. Service group is a resource type. A pre defined WSDL file for this resource type, capabilities like WS-Notification producer, WS-resource Property,WS-resource lifetime and Service Group registration are supplied to the API designed by Andrew which will produce the merged WSDL, which will be checked in.
  • 2. Membership content rule class in the service group ecore model is added to the mrt ecore model. It has content element (Q-names) and membership interface class which need to be copied to that ecore model (i.e:porttypes).
  • 3. Now the mrt ecore model must have a field called ‘flag’ which will differentiate between the normal mrt file and service group mrt file. Depending on the mrt file it should open up with corresponding editor. Service group mrt file must contain a section to add the membership content rule to it. It should list the capabilities like WS-notification producer, WS-resource Lifetime, WS-resource properties and Service group registration capabilities.
  • 4. After user clicks on “New Service Group Definition” under “Management Instrumentation” in the new >>other , SG.mrt will be created and it will open up in the Service group editor with the ‘flag’ set to 1 indicating that it is a service group.So it will have a section where user can add, edit and delete the membership rule.
  • 5. When the user right clicks on the mrt file and clicks on “generate java code” SG.dd file will be created which will have the SG.mrt file in the resource type tab and the corresponding capabilities listed, which are not editable.So DD editor must be changed to incorporate service group definition.
  • 6. Just before the code generation, membership content rule must be persisted in the WSDL of the previously generated resource type (SG.mrt ) by creating a replica of it in-memory.

Membership rules editor:
The membership rules are resource property values. So the resource properties document for the service group resource contains not only these property definitions but their values as well. This will be persisted as initialization parameters for the service group or using the persistence mechanism. Membership rules is a set of rules that follow the schema specified in the WS-ServiceGroups specification. User can specify any number of membership rules for a resource. User also has the option not to provide any rules. A membership rule can be specified in terms of expected interface (port type to be implemented by member resource) or in terms of the content of the resource properties exposed by the resource. A rule can consist of both interface specification or content specification or only one of them. Each row represents a rule and the first column will be used to specify the porttype, the second for the content Qnames .i.e. Qnames of the child elements that must be present in the resource properties document of the member resource. This column can contain multiple qnames listed for each rule. Editor will contain three buttons.

  • New Rule: New Rule will bring up a dialog that contains an option to select the interface and content Qnames.
  • Specifying Porttypes: - Porttype can be selected from the available mrt files in the workspace.

    - As a stretch goal, allow user to specify an EPR, and connect to the resource at the EPR, do metadata exchange to get the WSDL and get the port type from it and show it to the user

    For Content QNames, - A browse option is provided, that can be used by the user to look at defined capabilities in the workspace an dpick the defined type names in XSDs of the those capabilities. - As a stretch goal, allow user to specify an EPR and connect to the resource at the EPR, show the resource properties document (by doing a generic QueryResourceProperty operation), and show the elements in that document for the user to pick up


  • Edit Rule: Edit rule uses the same dialog as New Rule uses, but will also populate the existing content of the selected rule in the dialog.
  • Delete rule: The Delete rule will delete the selected rule from the list.

Back to the top