[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 3/31/2005: Comment re: OriginalMessageIdentifier (Signal)[wd10-schema 2/22]
Working our way through Sacha Schlegel's comments: OriginalMessageIdentifier in SignalIdentificationInformation in signal schema. We decided in Tuesday's call to put additional description here. Hima, I need your feedback if the annotation for SignalIdentificationInformation is correct/acceptable. Thanks. Feedback on the proposed changes in line with our discussion welcome. Proposed changes: ===================================================================================================== Technical specification (from previous proposal) Section 4.6.6.3 Change from: The Signal element is used to specify both ebBP and user-defined signal schema references. The use of either is supported via the signal references in the BPSS and the business signal schema. Change to: The Signal element is used to specify both ebBP and user-defined signal schema references. The use of either is supported via the signal references in the BPSS and the business signal schema. The logical relationship between the BPSS, business signal and underlying messaging are visible via the schema constructs. See the appendices at the end of this document for BPSS and signal instances. ============================= BPSS schema Change from: - <#> <xsd:complexType name="*SignalEnvelopeType*"> - <#> <xsd:annotation> <xsd:documentation>The type of a Signal Envelope definition that conveys Business Action information. Note, this type was added in v2.0 for signals to mirror the Document Envelope structure (where applicable). A signal is used for state alignment.</xsd:documentation> </xsd:annotation> - <#> <xsd:sequence> <xsd:element ref="*Documentation*" minOccurs="*0*" maxOccurs="*unbounded*" /> </xsd:sequence> <xsd:attributeGroup ref="*name*" /> - <#> <xsd:attribute name="*signalDefinitionRef*" type="*xsd:IDREF*" use="*required*"> - <#> <xsd:annotation> <xsd:documentation>The nameID reference of the signal definition for the Business Signal.</xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> Change to: - <#> <xsd:complexType name="*SignalEnvelopeType*"> - <#> <xsd:annotation> <xsd:documentation>The type of a Signal Envelope definition that conveys Business Action information. Note, this type was added in v2.0 for signals to mirror the Document Envelope structure (where applicable). A signal is used for state alignment.</xsd:documentation> </xsd:annotation> - <#> <xsd:sequence> <xsd:element ref="*Documentation*" minOccurs="*0*" maxOccurs="*unbounded*" /> </xsd:sequence> <xsd:attributeGroup ref="*name*" /> - <#> <xsd:attribute name="*signalDefinitionRef*" type="*xsd:IDREF*" use="*required*"> - <#> <xsd:annotation> <xsd:documentation>The nameID reference of the signal definition for the Business Signal. This allows reference to BPSS or user-defined signal definitions. The signal definition may map to the BPSS signal schema and the underlying messaging.</xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> ============================= Signal schema Change from: <xsd:complexType name="*SignalIdentificationInformation*"> <xsd:annotation> <xsd:documentation>This defines the content structure for identiying various parameters pertaining to the business signal. "OriginalMessageIdentifier" captures the value of the message identifier for original message to which this signal is being sent. If business message has an identifier, that can be captured by the "OriginalDocumentIdentifier" attribute. "OriginalMessageDateTime" is the time when the original message was sent. "ThisMessageDateTime" is the time when this signal message is being sent. The following optional elements are there to provide access to information that can be used by processing logic outside the business process engine. One example of this could be a monitoring application which can use this information to provide status of a collaboration. "FromPartyInfo" describes the party id that is sending the signal message. "ToPartyInfo" describes the party id that is being sent the signal message. The roles described below are based on the implicit relationship between the partner sending the signal message and the partner who sent the original message to which this particular signal is being sent. The role relationship between partner sending the business message and the partner receiving it is captured in the BPSS document. "FromRole" captures the role being played by the party that is sending the signal message. "ToRole" captures the role played by the party that is being sent the signal message. "ProcessSpecificationInfo" type descibes the BPSS information which defines the runtime collaborations for which this signal is being sent "CollaborationIdentifier" is the unique identifer that associates the signal with a particular collaboration. This could come from the business message itself or in case of ebXML MSH, could be the messaging level header "ConversationId" "BusinessActivityIdentifier" identifies the business requesting or responding activity to which this signal is being sent. This would identify the "BusinessAction" from the BPSS document and could be implemented using the "name" attribute on either the REquestingBusinessActivity or the RespondingBusinessActivity</xsd:documentation> </xsd:annotation>......... Change to: <xsd:complexType name="*SignalIdentificationInformation*"> <xsd:annotation> <xsd:documentation>This defines the content structure for identiying various parameters pertaining to the business signal. "OriginalMessageIdentifier" captures the value of the TRANSPORT message identifier for original message to which this BUSINESS signal is being sent. If business message has an identifier, that can be captured by the "OriginalDocumentIdentifier" attribute. "OriginalMessageDateTime" is the time when the original message was sent. "ThisMessageDateTime" is the time when this signal message is being sent. The following optional elements are there to provide access to information that can be used by processing logic outside the business process engine. One example of this could be a monitoring application which can use this information to provide status of a collaboration. "FromPartyInfo" describes the party id that is sending the signal message. "ToPartyInfo" describes the party id that is being sent the signal message. The roles described below are based on the implicit relationship between the partner sending the signal message and the partner who sent the original message to which this particular signal is being sent. The role relationship between partner sending the business message and the partner receiving it is captured in the BPSS document. "FromRole" captures the role being played by the party that is sending the signal message. "ToRole" captures the role played by the party that is being sent the signal message. "ProcessSpecificationInfo" type descibes the BPSS information which defines the runtime collaborations for which this signal is being sent "CollaborationIdentifier" is the unique identifer that associates the signal with a particular collaboration. This could come from the business message itself or in case of ebXML MSH, could be the messaging level header "ConversationId" "BusinessActivityIdentifier" identifies the business requesting or responding activity to which this signal is being sent. This would identify the "BusinessAction" from the BPSS document and could be implemented using the "name" attribute on either the REquestingBusinessActivity or the RespondingBusinessActivity</xsd:documentation> </xsd:annotation>......... =====================================================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]