The Relationship Service

Introduction

Handcar supports an alternative service for accessing and managing relationships.  These relationships are exposed via the relationship service.  Key to understand is that they are organized by “families” not “objective banks” and to map between a bank and a family you need to call method to get the id of the family that corresponds to the bank you are working with.  So the pattern is to:

  1. Create a bank using the learning service
  2. Create objectives via the learning service
  3. Switch to the relationship service
  4. Use the Bank Id to get the Corresponding Family Id
  5. Use that Family Id to get and update the relationships between the objectives in the bank

See https://mc3-demo.mit.edu/handcar/contractdocs/HandcarRelationshipService.html

Objectives have the following known types relationships:

  • Parent-Child (for topic hierarchy)
  • Requisite/Dependent (for pre-requisite mapping)
  • Equivalent
  • Related
  • Corresponds
  • Strongly Corresponds

Each Relationship is an object that contains the following information:

  1. Id
  2. Name
  3. Description
  4. Genus Type
  5. Source id
  6. Destination id

See https://mc3-demo.mit.edu/handcar/contractdocs/RelationshipBean.html

If I can do pretty much everything I need via the learning service, why would I use the relationship service?

There are several reasons you might want to use the relationship service instead of the learning service:

  1. Efficiency Reason #1 – with the relationship service you can get ALL of the relationships of a particular type at the same time.   The implementation is faster as well.  Via the learning service you have to point to one objective and ask for it’s children traversing the hierarchy.  Yes there are bulk operations that can speed things up but you still have to traverse the hierarchy tree.
  2. Efficiency Reason #2 – with the relationship service you can get ALL of the relationships for ALL types of relations at the same time.  Most banks are not that large and if you are painting a screen with the objects and relationships the relationship service can get all that data in one call and very quickly.
  3. Extra Data – with the relationship service you can tag the relationship with extra data such as name or description or other extension data.  This allows you to display more detailed labels describing your relationships.  With learning service the names and descriptions are based on the type of the relationship.

If I can do pretty much everything I need via the relationship service, why would I use the learning service?

There are several reasons why you might want to manage the relationships via the learning service:

  1. Efficiency #1 – If you are painting the hierarchy tree one node at a time the learning service more naturally supports those kinds of operations.  You use that to get just the nodes you want to paint WITHOUT GETTING ALL of the relationships.
  2. Efficiency #2 – Most of the time the essence of a relationship is just that the the two ids on either end of the relationship.  The learning service exposes just the critical information that is really needed to manage most relationships.  I.e. you don’t have to specify all that “extra data.”
  3. Ordering – with the learning service, when you can add multiple children to an objective the ordering of those children is guaranteed to be preserved.  That is when you fetch back the children they will be retrieved in the same order.  With the relationship service you can only create one relationship at a time with no way to specify ordering of multiple relationships.

Can I use both in the same application?  (Do the two services really update the same data?)

Yes! Welcome to service oriented architecture.  Underneath, both services talk to the same database tables.  If for example you add 2 child objectives to another objective you can immediately turn around and fetch those as a PARENT-CHILD relationship.   Conversely if you add a REQUISITE relationship via the relationship service you can then ask via the learning service which objectives does this one depend on and it will return you the same result.  The beauty is that you can use whichever form best supports your particular application.