Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Bugzilla 165536"
| Line 95: | Line 95: | ||
<li>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.</li> | <li>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.</li> | ||
| − | <li>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.</li> | + | <li><b><i>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.</i></b></li> |
<li>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.</li> | <li>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.</li> | ||
| Line 103: | Line 103: | ||
<h2>Comments</h2> | <h2>Comments</h2> | ||
<li> 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.</li> | <li> 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.</li> | ||
| − | <li> NOTE: Design aspects related to “Relationships Resource” is yet to be included in this document.</li> | + | <li> <b>NOTE:</b> Design aspects related to “Relationships Resource” is yet to be included in this document.</li> |
Revision as of 04:58, 10 January 2007
Link to bug on TPTP (this is not part of the template): [1]
Contents
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:-
The “RelationshipType” model is shown above.
There needs to be a section in the MRT editor which captures all the relationship information. The relationships section would appear only when the “Relationships” capability is included into the MRT. It could look like this:
Clicking on “Add” button 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.
Clicking on “Browse” button will bring up the following dialog:
Select an MRT and click on OK. Fill up all the other details on the dialog and then click OK. This will populate the relationships table in the editor.
Extension points
Code interfaces
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.
- 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.
This could be the way we implement relationships to start with in our WSDM tooling but there is further scope for open discussion.