Tutorial4 (Drink with Style)

In Tutorial4 we build a mix comprising a solicit/response and two request/reply operations.

Having left your car at home, in Tutorial4 you can safely settle down to drinking - this time with style.

You once again send a single flag field, ORDER, to SPARKL to start the transaction.

SPARKL returns a response message containing the gin and tonic fields as mixed by the Barman.

The mix

The mix comprises a solicit/response and two request/reply operations.

The solicit/response operation is used to kick off the transaction in SPARKL.

The service that processes the transaction, using the initial solicit as its starting point, is the Sequencer service.

The Sequencing Graph is derived from all the operations in the mix.

The mix has the following components:

Sequencer
Sequencer, a service provisioned using the Sequencer extension processes the transaction starting with the initial operation.
Bartender
A service provisioned using the Expressions extension. It supports the request/reply operations and is invoked on demand by the Sequencer.
Order/Ok
An operation comprising a solicit with one possible response, implemented by the Sequencer.
AddGin/Ok
An operation comprising a request with one possible reply, implemented by the Bartender service.
AddTonic/Ok
An operation comprising a request with one possible reply, implemented by the Bartender service.
ORDER
A flag field sent to and from the operations. A flag field has no value and serves only sequencing purposes.
gin, tonic
Fields sent to and from the operations. They contain data in the form of a string.
Client/Server
Folders separating operations. Folders are optional and can be used to separate various components of a mix.

Figure: Tutorial4 - The mix


Explanation

The Sequencing Graph is generated from the operations of the mix.

The first vertex is generated by the solicit/response operation.

The other three vertices, and the edges connecting them, are generated by the two request/reply operations.

When a transaction is triggered by the initial solicit, the Sequencer can start toward either of the two possible directions.

No matter which way it starts first, the Sequencer will have to traverse both directions as the response goal event can be satisfied only when the Sequencer has all three fields.

See Figure 3 and Table 1 for a better understanding.

Figure: Tutorial4 - The Sequencing Graph


Table 1. Tutorial4 - Component roles
Component Markup Description
Order
<solicit 
  name="Order" 
  service="Sequencer" 
  fields="ORDER">
  <response 
    name="Ok" 
    fields="gin tonic"/>
</solicit>
Once it receives the single field ORDER, the Sequencer creates a new transaction and uses the solicit as its starting point.

The Sequencer determines that the response requires the two fields gin and tonic, neither of which yet exist in this new transaction.

The Sequencer determines that if both the AddGin and the AddTonic operations are invoked, it will get both those fields and it can satisfy the response goal.

AddGin
<request 
  name="AddGin" 
  service="Bartender" 
  fields="ORDER">
  <prop 
    name="expr.bind.out" 
    Gin="gin"/>
  <prop 
    name="expr.src"><![CDATA[
Gin = "Gordon's",
  "Ok".
  ]]></prop>
  <reply 
    name="Ok" 
    fields="gin"/>
</request>
The request/reply operations are both implemented by the Bartender service, who checks the shelves for gin and tonic.

Therefore, on demand by the Sequencer, SPARKL invokes the two request/reply operations, duly receiving gin as the reply from AddGin, and tonic as the reply from AddTonic.

The markup in the requests binds their output fields to Erlang variables. These variables are assigned a value in the expressions contained in the expr.src properties. The expression also names the reply, Ok, which is sent.

The Sequencer now has all three related fields, and is able to supply gin and tonic in a single message which forms the response to the initial solicit.

AddTonic
<request 
  name="AddTonic" 
  service="Bartender" 
  fields="ORDER">
  <prop 
    name="expr.bind.out" 
    Tonic="tonic"/>
  <prop 
    name="expr.src"><![CDATA[
Tonic = "Schweppes",
  "Ok".
  ]]></prop>
  <reply 
    name="Ok" 
    fields="tonic"/>
</request>
See above.

Bottoms up old chum!

Bartender
<service 
  name="Bartender" 
  provision="expr"/>
The service implementing the request operations is the Bartender service. As it is provisioned using the Expressions extension, operations on it can contain Erlang expressions.