Re: Internal processes and/or external choreographies (was RE: Ev ents and States ...

Burdett, David wrote:

>Assaf
>
>You seem to have a very clear idea of how both requirements (internal and
>external definitions) can be met by one language based on pi-calculus.
>
Or even two different languages which are simply designed based on some 
common principal to allow that.

>Unfortunately I, and probably many others on this list, are not familiar
>with pi-calculus.
>
>So can you provide an example (see below for the use case) in a single
>language that meets the requirements for internal and external definitions.
>I agree that we don't yet want an implementation, but understanding how it
>is possible will be useful in determining what we *should* do.
>
This is a very good example. First of all, it's fairly simple to read 
and understand and illustrate the point without getting into too much 
detail. We can talk about more advance uses later on, but I think this 
one is a good beginning. Second, it has the sufficient complication in 
the seller case to show why bi-simulation is needed (this may not be 
evident from the buyer case). And third, we can consider how this can be 
done in one language, or how this can be done in two different languages 
that simply adhere to some common principal.

I have elected to use a pseudo language. I don't want to marry this 
example to a particular syntax, we may end up deciding on a different 
syntax than the one used in WSCI/BPEL/BPML. I want to show that the 
principal works equally as well. We can imagine one language that 
depicts both "external" and "internal" definitions, or we can imagine 
two different languages. Using pseudo code we could imagine either 
possibility.

>Here's a very simple use case involving order placement - my favorite ;)
>
>**THE SINGLE EXTERNAL DEFINITION**
>
>CHOREOGRAPHY (This is the external definition)
>BUYER               SELLER
>1. Order ------------>
>... then either ...
>2. <------------ Order Response (to indicate the extent to which the order
>can be satisfied)
>... or ...
>2. <------------ Error Response (if there is a problem with the order which
>means it cannot be processed)
>  
>
Step 1: Define the choreography process as a combination of concurrent 
interacting processes.

process buyerSeller
  process buyer
  process seller

This construct is similar to the P = Q | R composition of pi-calculus. 
It's essential for the purpose of defining choreography, so a language 
that supports choreography requires such a construct. A language that 
doesn't support choreography has no use for such a construct. You will 
not find this construct in BPML, but you will find one (the global 
model) in WSCI. This construct can only depict all the processes that 
are concurrently active.

The use of 'process' here may be confusing. In the formalism both 
'buyerSeller' and 'buyer' are processes but are different types of 
composition. In an XML syntax it may be easier to use different elements 
name, so we may use 'model buyerSeller' and 'process buyer', or we may 
use 'choreography buyerSeller' and 'participant buyer' or we may have 
two different elements called 'process'. It's important not to get hung 
on the XML syntax, it's just syntactic sugar.


Step 2: Define the seller process as a sequence of activities performed 
by the buyer using send/receive actions. This is a guarded process that 
begins when the initial action is performed.

process seller
  receive order
  switch
     case conditionX
       send orderResponse
     default
       send errorResponse

The seller does nothing until it receives an order. Once an order is 
received there are two possible follow-up states: send an order response 
or send an error response. These states are mutually exclusive and the 
seller uses some internal decision to decide which state to perform 
next. In this particular example 'conditionX' is just an abstract name. 
It says absolutely nothing about the decision critera. It's only intent 
is to show that one of two cases would occur and that the decision which 
case would occur is up to the seller to make. It depicts what would 
happen, not why (as per your English definition of the choreography).


Step 3: Define the buyer process as a sequence of activities performed 
by the buyer using send/receive actions. This is process is not-guarded, 
it starts immediately upon the beginning of the choreography.

process buyer
  send order
  choice
    case 1
      recieve orderResponse
    case 2
      receive errorResponse  

This process is not guarded, it starts whenever the buyer decides to 
start it, and by sending an order message will also start the seller 
process. Again there are two possible cases, and the use of choice is to 
depict that either one will happen based on which message is received. 
Unlike the seller, the buyer does not decide which message to receive 
but rather waits for one of two messages to arrive.


>**THE TWO INTERNAL DEFINITIONS**
>
>BUYER PROCESSING 
>1. The Buyer's ERP system determines that an order needs to be placed
>2. The Buyer's system sends an Order to the Seller
>3. If an Order Response is received then it is forwarded to the Buyer's ERP
>system
>4. If an Error Response is received, then details are emailed to the IT
>department to investigate
>5. If no response is received after some time, then an email is sent to a
>user to phone the seller.
>  
>
Since I use the same pesudo language writing down the implementation, 
you can read this example as if the same language is used to define both 
choreography and implementation. That's one possibility. But it's also 
possible two use to different languages. For example, the implementation 
would need some way to map values from the ERP request to the order sent 
to the buyer, or from the order response back to the ERP system. This 
requires the language to be turing complete, so it can be done either as 
an extension of a non-turing complete language (e.g. adding XPath 
expressions to WSCI) or by using a turing-complete language (e.g 
BPEL/BPML/Java).

For brevity I didn't go into the details of how data is mapped from one 
activity to another. Imagine that the process has some properties, so 
when it receives a message it can put values into these properties and 
when it sends a message it can use these properties to construct a 
message. You can only construct a message using information you 
previously received or some global values that all processes could read. 
Adding these mapping rules/assignment would not change the model, so 
it's easier to omit them and keep the example short.

process buyerExec
  receive erpOrderDemand
  send order
  context
    event timeOut
      send noResponseAlert
    choice
      case 1
        recieve orderResponse
        send erpOrderResponse
      case 2
        receive errorResponse  
        send itErrorResponse

You will notice that the flow of the executed activities conforms to the 
specification given in the choreography, i.e. all the send/receive 
actions depicted in the choreography will occur in the same order 
subject to the same rules. But there are additional things that happen 
in the implementation and not described in the choreography 
(implementation details) while retaining conformance of the choreography 
and the implementation.

One way to see how the two map is to lay the choreography process over 
the implementation process.

The choice contains two mutually exclusive flows - either one will 
happen but not both. In this particular example the time-out event is 
processed concurrently with the choice. So when the time-out occurs, 
some user is notified with a noResponseAlert. The process still waits 
for a message to be received. The user can then phone the seller and 
request that the response be sent, or even receive the response over the 
phone and submit a response message on behalf of the supplier. 
Essentially the choreography is able to proceed past a "possible" 
failure, but handling of that failure is escalated to engage human 
intervention.

>SELLER PROCESSING
>1. The seller receives the Order
>2. The seller checks the order for validity.
>4. If there is an error then the Seller sends an Error Response to the Buyer
>5. If there are no errors then the Seller sends a credit check query to an
>external credit checking agency
>6. If the credit check fails, then the Seller sends an Order Response to the
>Buyer indicating this
>7. If the credit check is OK, then:
>  a) The Seller checks for stock availability with the Fulfillment system
>reserving stock as appropriate
>  b) The results from the fullfillment system are used create an Order
>Response
>  c) The Order Response is sent to the Buyer
>  
>
process sellerExec
    receive order
    invoke validityCheck
    switch
       case errorDetected
         send errorResponse
       default
          invoke creditCheck
         switch
           case noCredit
             send orderResponse
           default
             invoke checkAvailability
             send orderResponse

This example doesn't look as clear cut as the previous one. Instead of 
having one switch there are two switches here. The flow is definitely 
more complicated for the implementation that what is layed out in the 
choreography. Obvious, since the implementation deals with more details 
than the abstract choreography. Other implementations may be even more 
complicated. On top of that, there are two different activities that 
send an orderResponse.

Simply laying one definition on top of the other, it's not possible to 
see how this implementation conforms to the choreography. This is where 
bi-simulation comes in handy. You will notice that the implementation 
interacts with the buyer in exactly the same way as the choreography 
definition says it should. Specifically:

- In the state before 'receive order' nothing is sent to the buyer and 
only an order can be received
- In the state after 'receive order' nothing is received from the buyer 
and either errorResponse or orderResponse is sent back - not both and 
not twice (there may be two send activities, but only one will occur)
- In the state after 'send errorResponse' or 'send orderResponse' 
nothing is sent to or received from the buyer (but other things could 
happen not involving the buyer)

Essentially, and this goes back to Luciene's presentation during the 
F2F. The choreography specifies a set of states and what is expected at 
each state. The implementation can add additional states, or duplicate 
choreography states in different implementation states, but it does not 
add more choreography states or violates the transitions layed out in 
the choreography.

Even though the two definitions are diffrent they are still conformant. 
The implementation has flexibility in the variety of things it can do, 
but it respects the sequencing rules given in the choreography with 
respect to its participation in the choreography.

Comments?

arkin

>Do you think this example is OK?
>
>David
>
>
>  
>

Received on Saturday, 12 April 2003 17:37:51 UTC