Last week we submitted a talk at Eclipse Con 2010 “Add Complex Event Processing to your EMF models: Super Size models Fast food demo“. This is a good opportunity for explaining the concepts and architecture exposed in the talk. Actually that’s a good continuation of the last post. Indeed, we saw the M2M principles and the reasons why we needed transformation support and tracking of modifications from live-models.  Today we  put all those things in practise and dive into a real application example with live models, going further we use Complex Event Processing for injecting “intelligence” in the application.

Example to explain

In order to introduce all those new concepts, we use an application example for illustrating this post. Let’s imagine that we have to implement the integrated software of a Fast Food chain. The aim is to implement the software of each cash desk but also to send  orders to the kitchen.

Before finishing writing the last line of the requirement, the fast food manager tell you something like “ho, by the way, I would like to improve the quality of service, I mean increasing the “fast” not the “food ” (he is laughing … that’s a fast food manager joke for sure) then I would like to be able to take decision to increase or decrease the burger rate at the kitchen if conditions are met. Condition being something like more than 3 burger ordered within 2 mins. In addition as I haven’t got much seats in my restaurant, if there is too much people seated, and other still going in at the cash desk queues, I would like to slow down the burger rate, then, we increase the time spent in the queue and I can let finish people in the restaurant. New seat detectors will be installed in 6 months”.

How could we implement such an application with live models ?

Step 1: designing models

The first step is to design models for order, bill and kitchen planing. The cash desk create orders and when press finish, it creates the bill and send the request to the general kitchen burger planning.

Order: list of burgers and drinks. It is represented by an entry which contains the reference to a burger and its quantity.

Bill: contains the burger total price and the drink total price.

Planning: that’s the kitchen planning, once a burger is ordered, we plan its preparation. It can be represented by pipes of burger. The planning will we weaved with all orders.

Therefore, the basic element is Order. From Order, we can weave the Bill, this means that from an order we can derive the bill model value. In the same way, the kitchen planning can weaved from order as well.

What do you mean by “weaved”?

If the bill and order are weaved, it means that when we create an order, we create a bill and the value of the bill attributes will depend on the attribute values of the Order instance. The weaving definition will describe how the two models are linked and when it must be updated.

The “how” will be the transformation process between the source and target model while the “when” will be the modification event we attach to the process.

Will it be live? What does it means?

Yes it will! It means that we aren’t going to generate code from our EMF models, instead, the application is composed by live-models, the runtime representation of our models. In this case, no generation phase is required, our models are the application.

Step 2: defining the weaving

Weaving between Order and Bill

Let’s start by the simplest weaving. The bill must be updated each time the burger entry list or the drink entry list is modified. This asks the first important questions: “how can we know that this particular attribute has changed? and how can I start a process or a transformation to update correctly the bill model?”

By the weaver framework of course!  In the scope of the Wazaabi project, we designed the Weaver framework (presented in the last post). This framework is able to listen any particular change on models, either structural change or value change. In addition it enables developer to start a Synchronization process to update any other models deriving from the first.

Between our two live-models, we need to update the bill price each time a new entry is added or removed. The activity (a step in a weaving process) will be triggered by the event “list modified”. This activity is just a JAVA class which recomputes the burger total price or drink if the event has been emitted by the drink entry list.

The activity needs to receive input parameter, in our case, we set the entry list as parameter. Therefore, the activity has just to compute the total price and set the new value on the bill.

Weaving between Order and KitchenPlanning

The kitchen planning is composed by 3 queues, one for each burger. The idea is that the Activity “BurgerPlan” is triggered each time the timestamps is modified. Actually the timestamps is defined once the order is validated, and therefore, it should not change any more.

Why don’t you use M2M framework such as ATL?

The first reason, is that ATL does not support, currently, incremental support (see last posts), therefore, we need to re-generate the target model, which is not possible in our case, because we cannot replace the instance of models, such as planning kitchen. In addition it is much more powerful to detect small modifications, and update those impacts instead of re-generating the entire model, especially in important models.

In addition, the kind of process we have shown in those examples could require to call an external Web Service or to look-up config in DB, or any other actions not directly linked to the source model. This is definitely not possible in traditional M2M.

However, we want to use ATL for defining those updates. Indeed, ATL is really suited for defining links between source and target models, that’s why in our case the synchronization process could be defined in ATL. Today we are joining  ATL research, an initiative from ATLANMOD (the ATL’s creator) in order to unify researches led around ATL and finally , if it turns out that the new technology is interesting, integrating officially ATL.  In this project we are developing a full support of ATL transformation as activity process in the Weaver framework.

What about UI?

Good question. We have done a  great job ! We have defined our live-models and the weaving between them. Now, we just need to build UI on top of those models. Either we create an SWT UI bound to our models, one for the Cash desk for editing orders and printing Bills, and  one for the kitchen for printing the planning. Or we ca use Live-Model UI framework such as Wazaabi. In this case, we have to define a UI model for Order, Bill and Kitchen plan and just weave them with their corresponding live models. Once the UI is defined, the application can work, nothing else is required. The job is done !

However, do you remember that the fast food boss wanted to control the burger cooking rate according to current demand. In addition, soon, the boss will ask to include other contextual parameters, such as the number of available seats, or the location of the truck which delivers salads and burgers.  How could we define a flexible, maintainable, and intelligent system? We propose to use CEP concepts. But we will see it in the next post on Thursday!

Conclusion (Part1)

In this post, we saw how we can create an application with live-models, and why did we need to weave them. First, we designed our models and defined how we should weave them.  We showed the necessity to listen model modifications in order to synchronize each other. Finally a UI layer for editing models is required and the job is done !  On the next post, we will see how the Complex Event Processing can bring value in our Fast Food management. Going further, we will show how we could extend the Weaver for collecting events and reacting in real-time to the fast food context.

So, stay tuned if you want to find out what will bring the Complex Event Processing in Live-Model applications!