B.4 Relationship Service High-Level Design

Section 1 Screen Mockups

The Relationship Service will use the Relationship Composer and Relationship Browser to visualize its contents. The service itself will not have a visual component.

Section 2 Design Considerations

Several issues affected the design. This design overcomes several of the flaws in the other industry relationship service while avoiding much of the complexity of the previous relationship service design. The primary capability that existed in the previous version of the relationship but that is not included in the new design is the rich set of constraints (i.e., symmetric, antisymmetric, reflexive, transitive, etc.). There are no plans to include such constraints in the future because they do not provide sufficient value to warrant the increase in complexity and decrease in understandability of the design.

These were the major issues involved in the design:

• There was a desire to limit the number of CORBA objects created to one per relationship instance. The other relationship services are frequently criticized for requiring the instantiation of several CORBA objects per relationship instance, which is expensive and results in poor resource utilization.

• A desired feature of the Relationship Service was the capability to create new relationship types dynamically. Few other relationship services currently provide this capability.

• Another desired feature was a more straightforward use of the service when interacting with the Discovery interface.

• CORBA provides very limited support for object equality. This design does not explicitly address this issue nor does it require objects participating in a relationship to implement an interface that uniquely identifies an object instance. Flexibility in describing unusual relationship types was also desired, such as relationships between arbitrary configurations of groups of objects.

• The design needed to adhere to the development group's architectural principles, including minimal interfaces, concise abstractions, and reasonable scalability to support large-scale enterprise systems.

Section 3 Component Reuse

This component will use Objectstore to manage its persistence and Visibroker to manage its distribution. No other reuse of software is expected.

Section 4 Discovery Interface Use

The Relationship Service defines a class RelationshipBag, which is stored inside domain objects and accessed through the discovery interface. The Relationship Service modifies this class to add relationships to the RelationshipBag so that they can be accessed by clients to the business object in order to discover the specific relationships an object instance participates in.

Section 5 OMG IDL

This completely replaces the Relationship Service IDL, which was used in the Relationship Service implementations.

Complete IDL

#include <eiTypes>

module ei {
   module RelationshipService {
       struct Role {
              string roleName;
              string objectName;
              CORBA::Object relatedObject;
       };
       typedef sequence <Role> RoleSeq;

       struct RoleDef {
              string roleName;
              InterfaceDefSeq allowedTypes;
              long minCardinality;
              long maxCardinality;
       };
       typedef sequence <RoleDef> RoleDefSeq;

       struct RelationshipDef {
              string relationshipName;
              string relationshipDesc;
              RoleDefSeq roleDefs;
              boolean uniqueObjectName;
       };
       typedef sequence <RelationshipDef> RelationshipDefSeq;

       RelationshipFactoryFactory {
              exception CannotCreateRelationshipFactory {};

              RelationshipFactory create(in RelationshipDef
                 definition);
              void remove(in RelationshipFactory factory);
       };  // end interface RelationshipFactoryFactory


              exception CardinalityViolation {};
              exception UniquenessViolation {};
              exception ObjectTypeViolation {};
              exception InvalidRole {};
              exception NameMismatch {};

       interface RelationshipFactory {
              readonly attribute RelationshipDef description;

              Relationship create(in RoleSeq roles) raises (CardinalityViolation,
                     UniquenessViolation, ObjectTypeViolation,
                        InvalidRole);
              void remove(in Relationship relationship);
       };  // end interface RelationshipFactory
       interface Relationship {


              readonly attribute RoleSeq roles;
              readonly attribute RelationshipDef description;

              RoleSeq findRoles(in string objectName) raises
                 (NameMismatch);
              void addRoles(in RoleSeq roles) raises (CardinalityViolation,
                     UniquenessViolation, ObjectTypeViolation,
                        InvalidRole);
              void removeRoles(in RoleSeq roles) raises (CardinalityViolation,
                     InvalidRole);
       }; // end interface Relationship

       interface RelationshipBag {
              exception NameMismatch { };

              RelationshipSeq find(in string relationshipName);
              RoleSeq findRoles(in string relationshipName);
              StringSeq getRelationshipTypes();

       // The following two operations are used by the Relationship Service to
       // add Relationship reference to object if the RelationshipBag is available
       // through the discovery interface

              void addRelationship(in Relationship newRelationship,
                     in string objectName) raises (NameMismatch);
              void removeRelationship(in Relationship relationship);
       };  // end interface RelationshipBag
   }; // end module RelationshipService
};  // end module ei

Section 6 Population

This effort will define the following three relationship types.

Associated-With

This relationship is used to model general associations between two objects of any type. It provides a straightforward one-to-one mapping, can accept objects of any type, and constrains the two objects to have a different name assigned to their role. The relationship consists of two roles: Subject and Associated.

Composed-Of

This relationship is used to associate Spectra objects with other objects, with the semantics of one object being composed of a set of materials with the corresponding spectral signatures. It allows up to ten spectra to be associated with an object. There are two roles: a Subject role, which can be of any object type, and a Material role, which must be a Spectra object. All of the objects in the relationship must be assigned different names.

Produced-By

This relationship is used to associate an object, typically a Feature object, with the WorkItem or Business Process that created it. The relationship has two roles: the result role, which can be of any object type, and a process role, which must be an object of type WorkItem or BPO. The process role has a cardinality of exactly one, as does the result role. The result and process roles must be assigned different names.

Section 7 Representative Use Cases for Event Traces

The following use case will demonstrate the base capability of the Relationship Service.

VHP3c Associates Geographical Feature

The purpose of this use case is to associate a geographical feature with ancillary information to provide a more complete description of the feature.

Section 8 Client Profile

The following Java utility class will provide a more convenient, finer grained access to the information contained in the Relationship Service:

class RelationshipWrapper {
       RelationshipWrapper(RelationshipSeq relationships);
       RelationshipWrapper(ei::component eiObject);
       string Name();
       string[] RoleNames();
       string[][] RoleValues(string[] roleNameList);
       long count();
       long minCardinality(string roleName);
       long maxCardinality(string roleName);
       boolean uniqueName(string roleName);
       string[] allowedTypes(string roleName);
       string[] getObjectName(string roleName);
       boolean objectPlaysRole(string objectName, string roleName);
       boolean objectIsParticipant(string objectName);
};

Section 9 UML Class Diagrams

The UML class model for the architecture is shown in Figure B.5. The RelationshipFactory creates relationship objects. These objects are typically contained in a relationship bag. The factory itself has a factory-factory that supports independent distributed creation operations throughout the system.