OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [Fwd: [ebxml-bp] Refactoring/reorganizing choreography constructs forebBP 2.0]


Mike, Pete, and Jacques,
Here are the information I mentioned briefly today. I'll also be 
uploading today's ebBP notes and will cc: Mike so he can see the 
detailed discussion around the use of fork, join and decision. I'll 
query some of the implementers on your questions about if-then-else. One 
question ebBP is still discussing states and transitions, because the 
key for reusability (such as for IIC) is not to create 
cross-dependencies.  Note, this is a working draft discussion - we have 
more work to do. But the concept discussions are particularly relevant 
to your work.

We can discuss further your brief point today of using the BPSS to help 
generate test stubs......Thanks.

Note: Dale is the expert ...not me.

Dale Moberg wrote:

>Hi,
>
>Monica suggested that we begin discussion of some reorganizations that I
>have been developing to the BPSS choreography constructs. 
>
>I am including a first discussion document for refactoring Decision,
>Fork, Join, Transition, Start, Success, Failure.
>The schema changes are incomplete but will be sent when they become more
>stable.
>
>Basic procedure so far is: 
>1. Follow UML Activity Diagram and Statechart Diagram for choreography. 
>2. Try to blend in BPSS constructs, mainly confining the core concepts
>to the States (They are BTAs fundamentally).  
>
>This reflects my belief that the core concepts (BTs, UNCITRAL, signals)
>are what is most distinctive in BPSS, while the choreography is really a
>commodity scaffolding. Mostly the UML models in BPSS 1.x versions can
>stay the same so far.
>
>My intent has to make the BPSS easier to implement.
>
>The main incompleteness remaining is with nesting (no longer done with
>Transition) and CA (and OA). What I hope to propose is a way in which
>these complex state constructs can have their "return" statuses which I
>am calling ConditionGuard Values. The initial attempt is to add a
>Returns construct that specifies which, if any, of these statuses from
>the BinaryCollaboration or nested BT percolates back. This allows
>flexible semantics, ranging from "ignore all subordinate results" to
>test whether to transition to Success or Failure with respect to these
>values.
>I think that conforms to the semantics we now have (which has no real
>syntax associated with it). Following this,
>all that remains is to add in the Role binding constructs as needed.
>
><xsd:simpleType name="ConditionGuardValue">
>		<xsd:restriction base="xsd:NMTOKEN">
>			<xsd:enumeration value="ProtocolSuccess"/>
>			<xsd:enumeration value="AnyProtocolFailure"/>
>			<xsd:enumeration value="RequestReceiptFailure"/>
>			<xsd:enumeration
>value="RequestAcceptanceFailure"/>
>			<xsd:enumeration
>value="ResponseReceiptFailure"/>
>			<xsd:enumeration
>value="ResponseAcceptanceFailure"/>
>			<xsd:enumeration value="SignalTimeout"/>
>			<xsd:enumeration value="ResponseTimeout"/>
>			<xsd:enumeration value="BusinessSuccess"/>
>			<xsd:enumeration value="BusinessFailure"/>
>			<xsd:enumeration value="Success"/>
>			<xsd:enumeration value="Failure"/>
>		</xsd:restriction>
>	</xsd:simpleType>
>  
>


Refactoring the BPSS choreography constructs.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]