[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]