[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 7/13/2005: Role Binding Changes Summary
As a result of our meeting and decisions yesterday, here is the summary of schema and technical specification changes. Note, we are still pending example changes which are currently in work (for 2 conformant instances and three snippet examples). Comments welcome (for wd r06, Committee Draft Candidate): Section 3.4.2 [case change only to reflect schema changes that will be explained more fully later] Change from: Each party, as an abstract partner, assumes an abstract role in a Business Transaction. Those roles are always generic and labeled as requesting and responding roles. Change to: Each party, as an abstract partner, assumes an abstract role in a Business Transaction. Those roles are always generic and labeled as Requesting and Responding roles. Change from: Like a Binary (Business) Collaboration, a Business Transaction is a re-useable protocol between two abstract roles. The way it is re-used is by referencing it from a Binary (Business) Collaboration through the use of a BTA as per above. In a Business Transaction Activity the specific roles of the Binary (Business) Collaboration are assigned to the execution of the Business Transaction. As indicated in the previous section, a Business Collaboration may be composed within another Business Collaboration via a Collaboration Activity. Each abstract partner participates in the Business Collaboration and occupies different role (occupants) in the included Business Transactions. How the external role in a Business Collaboration maps to the roles defined within the enclosed Business Transactions is mapped to a series of role relationships. How this is accomplished using the Performs element and external role mapping is found later in Sections 3.4.5 (shows Multiparty interactions) and 3.4.10.1. Change to: Like a Binary (Business) Collaboration, a Business Transaction is a re-useable protocol between two abstract roles. The way it is re-used is by referencing it from a Binary (Business) Collaboration through the use of a BTA as per above. In a Business Transaction Activity the specific roles of the Binary (Business) Collaboration are assigned to the execution of the Business Transaction (explicit generic Requesting and Responding Roles). As indicated in the previous section, a Business Collaboration may be composed within another Business Collaboration via a Collaboration Activity. Each abstract partner participates in the Business Collaboration and occupies different role (occupants) in the included Business Transactions. How the external role in a Business Collaboration maps to the roles defined within the enclosed Business Transactions is mapped to a series of role relationships. How this is accomplished using the Performs element and external role mapping is found later in Sections 3.4.5 (shows Multiparty interactions) and 3.4.10.1. Section 3.4.9.1 1. Change from: The Requesting role performing the Requesting Business Activity and the responding role performing the Responding Business Activity are abstract (placeholders). These roles become explicit when the transaction is used within a BTA as part of a Business Collaboration. There is no need to make these roles concrete such as buyer or seller. In particular some Business Transactions, for example “Cancel Purchase Order” MAY be used either way within the same Business Collaboration as two different Business Transaction Activities. Role changes and role bindings are described in more detail later in this section. Change to: The Requesting role performing the Requesting Business Activity and the Responding role performing the Responding Business Activity are abstract (placeholders). These roles become explicit and specific in context when the transaction is used within a BTA as part of a Business Collaboration. In the Business Transaction, the abstract roles are declared. However, there is no need to make these roles concrete such as buyer or seller. In particular some Business Transactions, for example “Cancel Purchase Order” MAY be used either way within the same Business Collaboration as two different Business Transaction Activities. In practice, roles may be implicit such as initiator or responder. To promote consistency and support role switching where applicable, these implicit roles of the abstract partners are explicitly declared and can be referenced in the BT (Note: This change was added in v2.0.1). Role changes and role bindings are described in more detail later in Section 3. 2. Change from: A Business Action, an abstract element, is the holder of attributes that are common to both Requesting Business Activity and Responding Business Activity. This element cannot appear in ebBP instances. Irrespective of whether or not a Response Business Document is required (i.e. no DocumentEnvelope), a Responding Business Activity exists to bind the corresponding role and business action. Change to: A Business Action, an abstract element, is the holder of attributes that are common to both Requesting Business Activity and Responding Business Activity. This element cannot appear in ebBP instances. Irrespective of whether or not a Response Business Document is required (i.e. no DocumentEnvelope), a Responding Business Activity exists to support the mapping of the corresponding role and business action. Even when no Response Business Document is produced, there is a Responding Business Activity that occurs that receives and processes the Request Business Document. Each activity has roles bound and linked to it. Section 3.4.10.1 1. [initiatingRoleRef deleted from Performs] Change from: One of the roles is initiating the Business Collaboration. This is the role (or may be associated with the role that performs the activity) that sends the first message (i.e. Request) of the first BTA. The initial abstract partner roles of the parent Business Collaboration are bound to the roles of an inner Collaboration Activity, when there is an inner Collaboration Activity. The abstract partner roles, the roles bound and performed (such as the initiatingRoleRef), and how they relate are described in detail in Section 3.4.1. Change to: One of the roles is initiating the Business Collaboration. This is the role (or may be associated with the role that performs the activity) that sends the first message (i.e. Request) of the first BTA. The initial abstract partner roles of the parent Business Collaboration are bound to the roles of an inner Collaboration Activity, when there is an inner Collaboration Activity. The abstract partner roles, the roles bound and performed (such as the currentRoleRef in the Performs element), and how they relate are described in detail in Section 3.4.1. 2. [role mapping] Change from: Binary (Business) Collaboration Product Fulfillment has the following roles: Buyer and Seller and a BTA where Buyer is the initiator and Seller the responder. We have now established a role relationship between the roles Customer and Buyer because they are both initiators in activities in the related performing and performed Binary (Business) Collaborations. Change to: Binary (Business) Collaboration Product Fulfillment has the following roles: Buyer and Seller and a BTA where Buyer is the initiator and Seller the responder. The Business Transaction and its declared roles are used by the BTA. We have now established a role mapping and relationships between the roles Customer and Buyer because they are both initiators in activities in the related performing and performed Binary (Business) Collaborations. 3. [Performs] Change from: This functionality supports tracing and binding of roles of the Business Collaboration across and within multiple levels of nesting. Change to: This functionality supports tracing and binding of roles of the Business Collaboration across and within multiple levels of nesting. Roles can be mapped and referenced (via @nameID) through multiple levels of activity nesting. Section 3.8.2 1. Deleted initiatingRole and respondingRole refs referential constraints. 2. Change from: [Performs/@currentRoleRef] Every Performs element MUST have one @currentRoleRef attribute whose value matches the value of a @nameID attribute on a previously mentioned Role element. Note: Role elements are mentioned at the top-level of a ProcessSpecification (within the ExternalRoles element), and then in each Collaboration element (BusinessCollaboration, MultiPartyCollaboration, BinaryCollaboration) that is not an inner collaboration. After these contexts, roles are introduced in additional Collaborations that are referenced within a CollaborationActivity element. [Performs/@performsRoleRef] Exactly one of @performsRoleRef, @initiatingRoleRef, or @respondingRoleRef MUST be present under Performs. When @performsRoleRef is used, its value MUST be a @nameID value of a Role element that is declared in the next Collaboration context. Note: When a Role/@name is the same in both the current and the next Collaboration context, it is assumed to be the same Role, and so the Performs association is not needed. Performs is needed for Role switching (that is, when a participant that had been a buyer, now reenters the collaboration as a seller), to match up roles differing in names in, for example, included packages, and as needed elsewhere. Change to: [Performs/@currentRoleRef] Every Performs element MUST have one @currentRoleRef attribute whose value matches the value of a @nameID attribute on a previously mentioned Role element. Note: Role elements are mentioned at the top-level of a ProcessSpecification (within the ExternalRoles element), and then in each Collaboration element (BusinessCollaboration, MultiPartyCollaboration, BinaryCollaboration) that is not an inner collaboration. After these contexts, roles are introduced in additional Collaborations that are referenced within a CollaborationActivity element. [Performs/@performsRoleRef] Exactly one of @performsRoleRef MUST be present under Performs. When @performsRoleRef is used, its value MUST be a @nameID value of a Role element that is declared in the next Collaboration context. From a BTA, the @nameID value in the @performsRoleRef attribute must match either the @nameID value of RequestingRole or RespondingRole in the BT. There must be two Performs, and they must reference different Role elements in the BT (that is, one must match value of RequestingRole/@nameID and the other must match value of RespondingRole/@nameID. Section 3.8.3.5 [add] under Roles - Functional Constraints • A Performs element MAY not be omitted from Business Transaction Activities. This provides for discrete role declaration at the BTA layer. It maps the "role-as-defined-in-collaboration" to the "role-as-defined-in-transaction" and provides discrete declaration of roles for the Business Collaboration. Appendix G: Change from: A unit of work in a trading arrangement between two parties playing opposite (abstract) roles; consists of one or two predefined Business Document Flows; will attain a success or fail state Change to: A unit of work in a trading arrangement between two parties playing opposite (abstract yet declared) roles; consists of one or two predefined Business Document Flows; will attain a success or fail state Schema: 1. Delete initiatingRoleRef and respondingRoleRef attributes on PerformsType. 2. Add RequestingRole and RespondingRole on BusinessTransactionBase Type with annotations. Change from: <xsd:complexType name="BusinessTransactionBaseType"> <xsd:annotation> <xsd:documentation>The type related to the abstract superclass associated with Business Transactions.</xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element ref="Documentation" minOccurs="0"/> </xsd:sequence> Change to: <xsd:complexType name="BusinessTransactionBaseType"> <xsd:annotation> <xsd:documentation>The type related to the abstract superclass associated with Business Transactions.</xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element ref="Documentation" minOccurs="0"/> <xsd:element name="RequestingRole" type="RoleType"> <xsd:annotation> <xsd:documentation>Allows definition of the Requesting declarative role on the Business Transaction. This explicit, yet abstract, role facilitates role mapping. This element was added in v2.0.1.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="RespondingRole" type="RoleType"> <xsd:annotation> <xsd:documentation>Allows definition of the Responding declarative role on the Business Transaction. This explicit, yet abstract, role facilitates role mapping. This element was added in v2.0.1.</xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> Add schema metadata as per OASIS draft artifact guidelines: <!-- Metadata: Owner: ebxmlbp (OASIS ebXML Business Process TC) Product: ebxmlbp (aka ebBP) Product Version: 2.0.1 Artifact Type: Schema Stage: wd (Committee Draft Candidate) Descriptive Name: None required Revision: r06 Language: en (English) Form: xsd (schema) Date: 20050713 (13 July 2005) -->
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]