Baker is a library that reduces the effort to orchestrate (micro)service-based process flows. Developers declare the orchestration logic in a recipe. A recipe is made out of interactions (system calls), ingredients (data) and events. A visual representation (shown below) of the recipe allows product owners, architects and developers to talk the same language.

An introductory presentation of Baker could be found here: Baker talk @ Amsterdam.Scala meetup

An example web-shop recipe you can find at: ExamplesSpec

WebShop Recipe:

  val webShopRecipe: Recipe =
    Recipe("WebShop")
      .withInteractions(
        validateOrder,
        manufactureGoods
          .withRequiredEvents(valid, paymentMade),
        shipGoods,
        sendInvoice
          .withRequiredEvent(goodsShipped)
      )
      .withSensoryEvents(
        customerInfoReceived,
        orderPlaced,
        paymentMade)

A visual representation of the WebShop recipe looks like the following, where the events are colored in gray, ingredients in orange and interactions in lilac:

Baker consists of a DSL that allows developers to choose interactions from a catalogue and re-use them in their own recipes. Developers can use Java or Scala as a programming language. Each recipe is turned into a Petri net at runtime.

Petri nets have two interesting mathematical properties that we’d like to explore in the near future:

• reachability – can we deliver on a promise (recipe) at all – this will allow developers to check during compile time if the recipe they’ve created makes sense and achieves the desired end state (fulfills the customer order);
• liveliness – do we have steps in a recipe that make no sense (unreachable, “dead” code) – this will allow developers to create lean and mean recipes (the less code you write, the less bugs you produce, the less you support);

Let's look at three different products that a bank would sell to customers:

As you can see, there are similarities in the products.

It becomes interesting when you're able to combine the same interactions in different recipes. New functionality can then be built quickly by re-using what's already available.

Applying Baker will only be successful if you make sure that:

1. You've compared the products your company is selling and there are similarities;
2. You've defined a catalogue of those capabilities necessary to deliver the products from;
3. Each capability (interaction in Baker terms) is accessible via an API of any sort (could be a micro-service, web-service, so on);

To get started with SBT, simply add the following to your build.sbt file:

libraryDependencies += "com.ing.baker" % "recipe-dsl_2.11" % "1.1.12"
libraryDependencies += "com.ing.baker" % "runtime_2.11" % "1.1.12"
libraryDependencies += "com.ing.baker" % "compiler_2.11" % "1.1.12"

Execute the following commands in your terminal to get started with the development of BAKER.

$ git clone https://github.com/ing-bank/baker.git
$ cd baker
$ sbt
> compile

Baker can turn a recipe into a DOT representation. It can then be visualized using the following web-site (http://www.webgraphviz.com).

Another way to visualize the recipe is to install Graphviz on your development machine. On your Mac, install using brew:

brew install graphviz

To test that all works fine, save the following text in a graph.dot file:

digraph d {
A [label="Hello"]
B [label="World"]
C [label="Everyone"]
A -> { B C }
}

To create a PNG, run:

dot -v -Tsvg -O graph.dot

Preview the results:

open graph.dot.svg

You are all set to visualize your recipes now!

You can also use custom fonts, for more info see http://www.graphviz.org/doc/fontfaq.txt.

Each interaction can be:

1. Synchronous - wait on a response;
2. Or asynchronous - get an acknowledgement only, while the outcome is received later;

Model the result of a synchronous interaction with two events: Successful and Failed. For example the ValidateOrder interaction could fire OrderValidationSuccessful or OrderValidationFailed events.

Model the acknowledgment from an asynchronous operation with an Accepted event. The actual result (received at a later stage) of the interaction is modelled as above.

1. DOT Graph Description Language (https://en.wikipedia.org/wiki/DOT_(graph_description_language)) - explain more about the format Baker uses to produce a graphical representation of the recipe;
2. Order fulfillment (https://en.wikipedia.org/wiki/Order_fulfillment) - gives an idea about the theory behind order fulfillment strategies. As you are in the business of producing and selling products to people, you are in the business of fulfillment;