Bugzilla 165536

Discuss this feature

Link to bug on TPTP (this is not part of the template): [1]

TPTP feature: 165536

Author:	Arun Shivaswamy
email:	ashivasw@in.ibm.com
Committer email:	bsubram@us.ibm.com(Balan Subramanian)
Last updated:

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

Process	Sizing
Design	1
Code	5
Test	2
Documentation	1
Total	9

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

Requirement summary

• WSDM Tooling would need to allow users to build relationships between two or more manageable resource types. This would help in building related endpoints to manage the underlying resource.

User interactions

The relationships model as defined by OASIS is part of the muws-part2 specification and the ecore model looks something like this.

The main terminologies of interest to us are the following:

• Relationship Type
• Participant
• Role
• EPR of Self / Participant (which may not be available until runtime)

The following would be the high level design for the WSDM tooling: The ecore model for manageable resource type needs to include the one highlighted below:-

We can create an MRT file when you Click on New>>Other>>Tooling For Webservices Distributed Management>>New WSDM Manageability Endpoint Type.

In the MRT editor, there would an option to capture all the relationship information.
For this, in the MRT editor, a checkbox would be provided which specifies to add the Relationship capabilities to the current MRT. On selecting this checkbox, all the Relationship capabilities will be added to the MRT. The following screen depicts this.

A new tab 'Relationship Definition" will be added to the MRT Editor.

To add a Relationship Definition, click on “Add” button. It will bring up the following dialog:

NOTE: The “Type” of relationship is still not clear and I have just left it out as a textbox. Looks like it is an array of QNames which finally need to get into the RMD document of the Relationships capability but not sure.

Once a Relationship definition is added, we can add participants to it. Selecting the Relationship Definition, will enable the 'Add Participant' button. Clicking on “Add Participant” button will bring up the following dialog:

In this dialog, we can add either Participant Definition or the Participant ERP.
Note: In the above dialog, the label, "Participant" would be changed to "Participant Defintion".

To add Participant Definition, click on the "Browse" button in the "Add Participant" Dialog. It brings up the following dialog. This dialog lists all the Mrt's in the current workspace. Select an MRT and click on OK.


The Relationship definitons are added to the MRT as follows:

Design summary

• Relationships would need to be defined in the WSDM tooling as part of the Manageable Endpoint editor. This is because WSDM assumes that two or more resource types can be in a relationship although the specification says that it need not necessarily have to be resource types that participate in a relationship. It could be other web services as well which WSDM does not bother about as of today. We do not have other types of web services which can really be termed as WSDM components that can get into a relationship.
• NOTE that the DD editor is the one that groups together one or more resource types before the codegen takes over. We could have the relationships aggregated here for all the MRTs chosen before passing the information to codegeneration. This would mean consolidating all the relationships between chosen MRTs and making it part of the resourceProperties document of the final merged WSDL. This would demand some work that needs to be done in the DD code that hooks upto codegen.
• At the end of it all, we need to mandatorily include details about the Self-Type in the XMI for the resource type if atleast one relationship exists just to make sure that the resource type in question is a self participant and hence subsequently denote its role in the relationship. So, when we have relationships between resource types, we need to have two entries made into the generated XMI for a resource type, one denoting the self-type and the other denoting the participant type.

This could be the way we implement relationships to start with in our WSDM tooling but there is further scope for open discussion.

Comments

• Not sure on how to deal with EPRs for Self/Participant since we may not really have the EPRs of either of them while defining the relationship.
• NOTE: Design aspects related to “Relationships Resource” is yet to be included in this document.




Additional Comments

one thing that does not come out in the design is that relationships can be realized in two distinct ways. the first is that they become a pointer from one resource to another. in this case, the "owning" resource simply maintains an EPR to the other resource. it's not clear to me how this will be handled in the rest of the tooling, e.g. is there a slot in the deployment descriptor to put this in etc...

the second way is that the relationship itself is a ws-resource. where does this get surfaced? in this case, how do you set/establish the resource lifetime of the relationship resource? what service group is it added to on startup? where does it send it's events?

relationships are established b/t capabilities, not the resource type. the resource type has the resources of it's capabilites.

an example of the muse deployment descriptor with the relationship information should be included in this design document as well.