W3C home > Mailing lists > Public > public-ws-chor@w3.org > February 2004

Fwd: Monica's stuff

From: Steve Ross-Talbot <steve@enigmatec.net>
Date: Sun, 29 Feb 2004 15:52:13 +0000
Message-Id: <3E0640C8-6ACF-11D8-8369-000393D13C9A@enigmatec.net>
Cc: WS Choreography (E-mail) <public-ws-chor@w3.org>
To: "Monica J. Martin" <monica.martin@sun.com>

Dear Monica,

Martin and I spent quite a while on the requirements document in Dublin 
a week ago. One thing we did after our meeting was go back to your 
usecase which was included in the last version of the reqdoc.

Our take on the use case is documented below. We believe there to be 
one fairly important requirement that is not covered in the document at 
all. As such we have suggested a variation on usecase 2 to incorporate 
this requirement.

We would welcome you thoughts on this at the F2F.


Steve T

Begin forwarded message:

> From: Steve Ross-Talbot <steve@enigmatec.net>
> Date: 23 February 2004 17:54:36 GMT
> To: Martin Chapman <martin.chapman@oracle.com>
> Subject: Monica's stuff
> From Monica's use case (for requirement 2):
> 2. Approver receives credit information and service processing begins 
> based on credit information
> provided. [1..n correlation sets]
>     a. The approver asks the FICO checker for a credit score. This 
> child process is dependent on the
>         approval process.
>             i. The credit score may require additional credit score 
> decisions by the approver: base credit
>                and/or variable credit rating and credit rating type.
>            ii. The approver may require a variable rating may be 
> required in the same or separate interaction
>                to the assessor. [Different operations on same portType]
>           iii. If a variable rating is required, it can be provided in 
> a separate interaction at the original request
>                of the approver.
>           iv. The approver may choose to suspend the risk assessment 
> based on the credit score.
>   b. Credit information is provided to one or more assessors for 
> evaluation, either in one or more communications
>        by the approver [Broadcast]
>             i. Gross income base provides an indicator of the ratings 
> required on the risk. [multiple variables,
>                possible different operations on same portType]
>   c. The approver has the right to ask the assessor to suspend a 
> response to further review a late submission
>       of credit information or to respond to the FICO checker results 
> that impact that risk assessment.
>             i. The approver will specify whether or not processing 
> continues by the assessor.
>            ii. The approver may specify processing continues but a 
> response cannot be
>                provided until the complete assessment can be provided. 
> [suspend, resume]
> Note:
> In this first part of this alternate path case, the Approver-Assessor 
> action is suspended or delayed in order to allow receipt of
> additional information from the Customer. How and if this information 
> is shared between the roles (or the participants) is dictated
> by the agreement between the parties _ business not technical 
> agreement. This may show how business semantics could be
> made available via the business collaboration description to the 
> choreography in order to implement the technical contract.
> My take:
> This is just an alternate path in which the CDL designer(s) should 
> model explicitly the observable behaviour wrt the suspend/resume.
> In order words the observable decision to suspend or resume could be 
> modeled as part of the base choreography. It would be a good
> debate to have at the F2F because one could imagine a situation in 
> which the flow of a choreography determines the paths it might
> take and the time delays that might be used as well as the criteria 
> for a join. So in a sense we could look at this as a generic dynamic
> join in which the flow determines the conditions for success on the 
> join and so determines when to proceed to the next observable
> state. It's kinda easier to draw this rather than describe it. By way 
> of a variation it might be that a CDL for UC002 includes something 
> like
> the following:
> Variation
> ------------
> A buyer is in communication with various suppliers who are in turn in 
> communication with various manufacturers. At the order placing stage
> between supplier and manufacturer the supplier places orders with 
> several of the manufacturers in parallel with some delivery date 
> checks
> with the manufacturer. When the order is placed the QA function 
> discovers a problem with one of the manufacturers. They don't want to 
> cancel
> the order unless the situation cannot be resolved within 2 weeks. From 
> a business perspective the supplier want to suspend further activity 
> with
> the specific manufacturer until the issue is resolved. From a CDL 
> perspective this can be modeled as part of the overall external 
> observable
> behaviour. All that should be required is to make it explicit in the 
> CDL description that this is part of the QA choreography (a named sub
> choreography) for the purpose of clarity and possibly so that business 
> tools may extract such information for auditing or monitoring 
> purposes.
> From Monica's use case (for requirement 1):
> 3.     Once the assessor(s) has(ve) evaluated the credit information, 
> a risk assessment is provided to the approver.
> a.     If a separate interaction is required, this is a sub-process of 
> the risk assessment between the assessor and approver. [subprocess]
> b.     If credit information is missing to effectively provide a risk 
> assessment, either, based on specific rules, either could occur:
>                                                 i.         Request for 
> more information from the approver (and to the customer).
>                                                  ii.         Error and 
> reply to the approver to reinitiate the process.
> My take:
> See above since this is simply a case of tagging sub-choreographies 
> with descriptive names which may have no value other than at the 
> business
> level. Although it might be nice to think of them as having unique 
> names (aka a URI).
Received on Sunday, 29 February 2004 12:05:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:03 UTC