Issue 3980: Separation of Collaboration from Encounter inheritance. (negotiation-ftf) Source: OSM (Mr. Stephen McConnell, mcconnell@osm.net) Nature: Uncategorized Issue Severity: Summary: Negotiation FTF, CollaborationFramework module. The definition of Encounter combines the notion of a Membership and rules relating to member association with rules relating to process execution (e.g. derived Collaboration interface). In the case of Collaboration the current inheritance model eliminates the possibility for independent declaration of process focuses role models as distinct from the roles attributed to different members of a membership. While the object model expressing roles from the two different perspectives are equivalent at an interface level, the instance values and lifecycles are independent. It is recommended that the notion of Encounter be restricted to the management of a set of members, sharing a common view on a collaborative process execution. Moving the collaboration process semantics out of the Encounter inheritance hierarchy can be achieved by defining a relationship between Encounter and the active process that an Encounter is co-ordinating. Once the notion of process is separated from the notion of membership, the respective control models can coexist. Secondly, given formal separation of Membership and process, the existing usage relationships derived from the inherited Task interface by Encounter can be used to manage the subject of collaborative interaction - as such, the subject relationship can be removed from Engagement, Voting and Collaboration. Resolution: - introduced explicit definition of a processor as a base type for collaboration, associated to a Task by a declared relationship - introduced explicit definition of a processor as a base type for Collaboration (as per Task Session notion of Task and processor) - retract the association of a subject of a collaboration in favour of the existing usage relationships between a processor and a Task. Resolution: see below Revised Text: Issue 3980 raises the potential for substantial interface simplification and improvements in clarity of the overall specification of collaborative interaction. Resolution of changes to incorporate separation have to large extent eliminated the semantic overloading of the Collaboration apply operation and have resulted in improvements in the reuse of Task and Session notions of resource usage. Impact on the CollaborationFramework specifications is summarized below. Revisions to the Encounter Interface Encounter has been modified to remove the direct declaration of the defining model (now accessible through the abstract Simulator interface inherited through Membership), and retraction of the subject association – supported by the addition of valuetypes within a ProcessorModel that declare usage association preconditions on its coordinating Task. The original definition of the model of an Encounter is now redundant as an Encounter (separated from processing semantics) is fully defined based on a MembershipModel valuetype exposed under the EncounterCriteria valuetype. interface Encounter : Session::Task, CommunityFramework::Membership { };valuetype EncounterCriteria : CommunityFramework::Criteria { public CommunityFramework::MembershipModel model; }; Specification of Processor and supporting valuetypes Separation of processing semantics from Encounter enables separation of control policy concerning a particular community of members from the execution policy of a particular collaboration. This separation introduces a significant simplification of at the level of application level processes such as Collaboration. A ProcessorModel declares the usage association preconditions that a particular processor imposes on the associated Encounter. ProcessorModel serves as a base valuetype to CollaborationModel, EngagementModel and VoteModel, replacing the equivalent Template interface definitions. abstract valuetype UsageDescriptor { }; valuetype InputDescriptor : UsageDescriptor { public string tag; public boolean required; public TypeCode type; }; valuetype OutputDescriptor : UsageDescriptor { public string tag; public TypeCode type; }; valuetype ProcessorModel : CommunityFramework::Control supports CommunityFramework::Model { public UsageDescriptors usage; }; The Processor interface has been defined based on the semantics implied by the Task and Session specification. It serves as a base type for the Collaboration, Engagement and Vote processor definitions used in conjunction with collaborative processes such as negotiation and multilateral engagement. Two abstract interfaces Master and Slave have been included to support the association of one process to another as a controlling processor relative to subsidiary processors. While the adopted specification describes this behaviour, the interfaces do not explicitly separate process to sub-process relationships. Processor exposes an operation named coordinator that returns the controlling Task (e.g. an instance of Encounter). Other operations are derived directly from the implied semantics detailed in the Task and Session specification. abstract interface Master { SlaveIterator slaves ( in long max_number, out Slaves slaves ); };abstract interface Slave { readonly attribute CollaborationFramework::Master master; }; interface Processor : Session::AbstractResource, CommunityFramework::Simulator, Master, Slave { readonly attribute StateDescriptor state; Session::Task coordinator( ) raises ( Session::ResourceUnavailable ); CommunityFramework::Problems verify( ); void start ( ) raises ( Session::CannotStart, Session::AlreadyRunning ); void suspend ( ) raises ( Session::CannotSuspend, Session::CurrentlySuspended ); void stop ( ) raises ( Session::CannotStop, Session::NotRunning ); }; Exposure of Processor state has been declared using valuetypes that supplements the state defined in Task and Session with an exploit declaration of Completion status. The Completion valuetypes simplify 1.0 control structures that qualified the result of collaboration model actions. valuetype Completion { public ResultClass result; public ResultID code; }; valuetype StateDescriptor { public ProcessorState state; public CollaborationFramework::Completion completion; public CommunityFramework::Problems problems; };Modifications to the definition of Engagement, Vote and Collaboration The interfaces Engagement, Vote and Collaboration have been revised such that the principal base type is Processor instead of Encounter. This revision enables the possibility for a single Encounter to switch from one process to another without requiring reconstruction of a new Membership structure. In each case, the operations specific to the type have been separated out into an abstract interface that is inherited by a concrete interface. Valuetypes defining processor models and criteria are defined as replacements for the corresponding Template interfaces from version 1.0. As a result of these changes the declaration of the 1.0 Manifest type is redundant and has been withdrawn. The following two interface replace the version 1.0 Engagement interface definition. abstract interface Engagement { Proof engage( in CollaborationFramework::Evidence evidence ) raises ( EngagementProblem ); }; interface EngagementProcessor : Engagement, Processor { }; The following valuetype replaces the version 1.0 EngagementTemplate interface. valuetype EngagementModel : ProcessorModel { public CommunityFramework::Role role; public Duration lifetime; public boolean unilateral; }; The following two interface replace the 1.0 definition of the Vote interface. abstract interface Vote { readonly attribute VoteCount vcount; VoteReceipt vote( in VoteDescriptor value ); }; interface VoteProcessor : Vote, Processor { }; The following valuetype declaration replaces the 1.0 definition of VoteTemplate interface.valuetype VoteModel : ProcessorModel { public VoteCeiling ceiling; public VotePolicy policy; public boolean single; public Duration lifetime; }; The definition of Collaboration is replaced by the following two interfaces. An important simplification of the semantic of the apply operation (detailed under EC/2000-11-14) has been achieved as a result of rationalization of the CollaborationModel exposure of usage constraints and usage modification directives. abstract interface Collaboration { readonly attribute Label active_state; readonly attribute TimeoutSequence timeout_list; void apply( in Label identifier ) raises ( InvalidTrigger, ApplyFailure ); void apply_arguments( in Label identifier, in ApplyArguments args ) raises ( InvalidTrigger, ApplyFailure ); }; interface CollaborationProcessor : Collaboration, Processor { }; The following valuetype replaces the CollaborationTemplate interface. valuetype CollaborationModel : ProcessorModel { public CommunityFramework::Role role; public CollaborationFramework::State state; }; Specifications of valuetypes and revised interfaces concerning the above revisions shall be taken from EC/2000-11-14. UML for all interfaces and valuetypes is presented at the end of each module specification in the consolidated specifications (EC/2000-11-14). „ CollaborationFramework UML, pages 79-82 „ CommunityFramework UML, page 115. Actions taken: October 23, 2000: received issue February 27, 2001: closed issue Discussion: End of Annotations:===== From: "Stephen McConnell" To: "Juergen Boldt" Cc: , Subject: Negotiation FTF issue - separation of Collaboration from Encounter Date: Mon, 23 Oct 2000 14:16:59 +0200 Message-ID: <000001c03ceb$24ccb330$0a01a8c0@osm.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Content-Type: text/plain; charset="Windows-1252" X-UIDL: *Z7!!D]dd92lB!!bZO!! Issue # XXXX Stephen McConnell" Separation of Collaboration from Encounter inheritance. Negotiation FTF, CollaborationFramework module. The definition of Encounter combines the notion of a Membership and rules relating to member association with rules relating to process execution (e.g. derived Collaboration interface). In the case of Collaboration the current inheritance model eliminates the possibility for independent declaration of process focuses role models as distinct from the roles attributed to different members of a membership. While the object model expressing roles from the two different perspectives are equivalent at an interface level, the instance values and lifecycles are independent. It is recommended that the notion of Encounter be restricted to the management of a set of members, sharing a common view on a collaborative process execution. Moving the collaboration process semantics out of the Encounter inheritance hierarchy can be achieved by defining a relationship between Encounter and the active process that an Encounter is co-ordinating. Once the notion of process is separated from the notion of membership, the respective control models can coexist. Secondly, given formal separation of Membership and process, the existing usage relationships derived from the inherited Task interface by Encounter can be used to manage the subject of collaborative interaction - as such, the subject relationship can be removed from Engagement, Voting and Collaboration. Resolution: - introduced explicit definition of a processor as a base type for collaboration, associated to a Task by a declared relationship - introduced explicit definition of a processor as a base type for Collaboration (as per Task Session notion of Task and processor) - retract the association of a subject of a collaboration in favour of the existing usage relationships between a processor and a Task. Stephen J. McConnell, OSM sarl digital products for global business http://www.osm.net mailto:mcconnell@osm.net