Skip to main content
Jump to: navigation, search

Bugzilla 165556

Discuss this feature

TPTP feature: 165556

Author: Krishna C Shastry
Committer email: Subramanian)
Last updated:

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

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 Service Group, the user must be able to define the membership constraint rules using the service group definition tab of the Manageability Resource Type Editor.

User interactions

User interface

When you Click on New>>Other>>Tooling For Webservices Distributed Management>>New WSDM Manageability Endpoint Type, the following wizard page will come up. None of the capabilities are added to the MRT definition as a default. User can add Service Group related capabilities or WS-Resource With Meta Data exchange related capabilities by selecting the appropriate check box. If a user selects Service Group Type, then the following capabilities will be added to the MRT definition.
1) WS-resource Property.
2) WS-resource lifetime.
3) WS-Notification Producer.
4) WS-resource properties.
5) Service group registration capabilities.
6) WS-MetadataExchange capability.


The rest of the flow in Wizard pages is as per the design document for MRT Editor. The following is the screen capture of Capabilities Selection Wizard page of MRT editor. You can notice that the Service group related capabilities are selected, since we have checked Service Group Definition in the previous page of the wizard.



In the MRT Editor, user can select/unselect the Service Group Type. Accordingly, service group related capabilities will be added/removed from the MRT definition. Also, whenever Service Group Definition is selected, a new tab (SG Definition) will appear in the MRT Editor. User can use this tab to define membership rules for the Service group. Add, Delete and Edit buttons can be used to add, remove and edit membership rules respectively.


In the SG Definition tab, the following dialog will come up whenever a user clicks on ADD button


Clicking on AddQNames button in the above dialog will bring up another dialog with a list of QNames defined in the capabilities available in the current workspace. User can select the QNames that will need to be part of the membership definition and press Ok to add them to rule.


Here user can delete previously selected QNames.


The following table lists the membership rules defined for a service group definition.


The Service Group MRT definition thus created as shown in the above mentioned procedure will contain one or more elements of MembershipContentRule type(<membershipContentRule ruleName="MyRule">) that will have a list of Qnames(contentElements) as its child elements.


To change the contents of a rule, select the rule to be edited and press Edit button. A dialog comes up where user can change the rule name and/or modify the QNames(Add additional QNames or Delete the existing QNames as mentioned previously for ADD operation) and press OK.



When a users open the MRT file in Text Editor, they can notice the changes in content.


To remove a content rule ,select the rule to removed and press Remove Button. The corresponding membershipcontentrule element in the MRT definition file will be removed.


Extension points

Code interfaces

Design summary

Service Group editor is added as another page to the existing MRT editor.So while creating the MRT file,wizard page will contain two check boxes namely i) Service Group ii) Mata Data Exchange Whenever user selects the service group check box corresponding capabilities will be added to the mrt model and a SGDefinition page will be added to the mrt Editor.In this page user can add,edit and delete the rules.

  • 1. Service group is a resource type. A pre defined WSDL file for this resource type, capabilities like WS-resource Property,WS-resource lifetime,WS-Notification Producer and WS-MetadataExchange are supplied to the Code Generation API, which will produce the merged WSDL, that will be used in the runtime.
  • 2. Membership content rule class in the service group ecore model is added to the mrt ecore model. It has content element (Q-names).
  • 3. MRT wizard page will contain two check boxes to select Service Group or MetaData exchange.For Service Group WS-resource Property,WS-resource lifetime,WS-Notification Producer,WS-resource properties ,Service group registration capabilities and WS-MetadataExchange capabilities will be added.For MetaData Exchange WS-MetadataExchange capability will added.
  • 4. After user clicks on "New WSDM Manageable Endpoint Type" under "Tooling for Web Service Distributed Management" in new >>other, a wizard page will come up, where user can select either service group or meta data exchange.On clicking finish all the corresponding capabilities added to the model and as told earlier a page will be added to the existing mrt editor, 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” corresponding .dd file will be created which will have the .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 (.mrt ) by creating a replica of it in-memory.
  • Service group editor is going to take care only the membership content rule.

Membership rules editor:
This will be enabled only when user selects service group check box. This will contain table tree viewer to accommodate membership rules.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 the content of the resource properties exposed by the resource. A rule consist of content specification. Each row represents a rule and the first column will be used to specify the rule name, 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.

  • Add Rule: New Rule will bring up a dialog that contains an option to select the content Qnames.
  • For Content QNames, - A browse option is provided, that can be used by the user to look at defined capabilities in the workspace an pick 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.

Code Generation for Service Group MRT Definition

  • Create Service Group RMD file and check in to Artifacts folder in the "" package.
  • During code Generation ,it will check whether MRT definition contains Service Group Capability or not.If MRT definition contains Service Group capability then copy the Service Group RMD file and Service Group capability file into the Workspace and make the MRT definition to refer to this capability.
  • Membership Content rules defined for the service group is copied into the service group RMD file.
  • Code generation part will take this as input and produce the corresponding web project
  • In future instead of storing membership rules into RMD file,we have to maintain an in-memory model of the RMD file and modify it during the code generation.

Back to the top