A few months after the installation and a successful implementation of our solution, an SOS emergency phone call reached our service center at 1 am: 

 ” … Our central storage system crashed and although we switched to the standby-database, the database did not start. Could you please help us …” 

I think the fact that catastrophes in the IT sector always happen at night should be officially added to the Murphy law book. On the other hand, in times of globalization this phenomenon will probably die out. 

 In addition it is interesting to note that although this customer did not buy our SLA service he knew whom to call… Never mind! 

Anyway, our professionals quickly found out that the synchronization process which was supposed to keep the standby database up-to-date stopped working two weeks ago. Although this database could be opened it would not have presented the actual data. 

The customer was lucky in this case, as we were able to recover the data from the crashed central storage and after an all-in-all outage of six hours the site was up and running again. 

Almost every technological solution aimed at increasing the availability of a system will automatically also increase the complexity of the underlying infrastructure, as well as the daily maintenance effort. 

I am aware that it is quite difficult to explain to a finance department of a company why they should spend more money on addtional hardware, which is solely used to ensure the availability of some applications without gaining any additional benefit in terms of functionality or performance. One way to convince a CFO might be to compare it to buying insurance. An insurance policy will only be useful when something unexpected happens. This comparison unfortunately does not give any reasonable explanation for the higher daily maintenance cost. Let me be very clear: The higher the complexity of an infrastructure, the higher the maintenance cost. This additional cost is not used for the activation of a solution in case of a crash but is aimed to cover the additional effort necessary to keep the normal operation up and running. 

In conclusion, and perhaps a bit provocatively I would like to state: 

IT infrastructure that was expanded to comply with a certain higher availability will be more liable to outages than before the expansion, without the appropriate daily maintenance. 

Yours 

Ariel Rauch

Case Study:

A company exists that is in charge of keeping track of vehicles via satellite sensors installed in their machine. The purpose is to be able to track all different sorts of statistics about the car and the drivers. When they turn their engines on a unit called a “trip” is started. When they turn their engine off, the “trip” is ended. These trips and all the data associated with them are sent via the sensors into a central SQL Server database.

The company would like to glean from this “sensor data”, information regarding the trip. For example they expect to view the following information:

• Who the driver was
• How much fuel was consumed
• Where they drove
• How well the driver drove
• In the case of a transport vehicle carrying refrigerated items, what the temperature was in the storage compartment

Depending on how sophisticated the sensors are, this data, as well as a myriad of other information, can be tracked and stored in the database. To simplify, we will take a few simple points of interest.

Database Overview:tblVehicles – Has a primary key called VehicleID

tblDrivers – Has a primary key called DriverID

tblTrips – Has a primary key called TripID. tblTrips is has many field that pertain to the upkeep and maintentance of the vehicle for a particular trip. For example: Fuel used, engine temperature, clutch movement, distance traveled, etc., Also the trip table stores which vehicle and driver is associated with the trip.

tblEvents – Has a primary key called EventID. tblEvents stores different types of events that can occur when driving a car. For example: Speeding, Passing, Wide turns etc.,

tblTripEvents – Has a duplicate key TripID, EventID. This table tblEvents stores the occurrences of these particular events that occurred during a trip.

tblTripsGrades – Has a triplicate key TripID, GradeType, GradeID. This table stores grades that are determined by computing the number of event occurrences for a certain trip. For example, Grade Type: Fuel Consumption, GradeType: Driver Safety

Specification:
The sensor company has many customers that own and operate many cars, transport vehicles. Every day the database fills with tremendous amounts of data regarding all the trips that each customer’s vehicles have travelled. They want to allow their customers to log on to a website and be able to view every detail about the vehicles, drivers and trips at lightning speed. They want to generate reports based on time periods so that can view how well a driver is doing, how many trips happened and grade the efficiency of the vehicles and drivers.

Attack:
We have all the information the customer needs stored in the database. The issue is that there may be hundreds of thousands if not millions of trips accumulated over a relatively short period of time. We need speedy access to this data. The first obvious approach is to define indexes on important fields in these tables and to write some scripts that join these fields to reveal the information.

The bottom line is: Regular indexes and “joins” in SQL Server scripts will not be fast enough. We need a way to view the information almost instantaneously. OLAP will allow you to create different views of this information from the perspective of dimensions and access them directly.

The next step is to define what the dimensions should be and how to use them.

A database design should be intuitive; thus allowing for queries that are easy to implement. Normalized Databases often store information in dozens or even hundreds of tables. This optimizes the performance for inserting and updating data. This is because a marginal amount of actual data is stored in each of those tables. Only a few tables are affected each time a SQL transaction is processed.

While all this may be true, once the database reaches a certain magnitude, querying the database becomes un-scalable. At that point, applications are developed to reduce the size of these databases which in turn combats retrieval times. As these relational databases grow in size, select queries take longer to execute. This is why indexing is an integral component of database design.

The more information stored in a well-designed relational database, there are more ways a user may want to gather data. A user may want to implement queries to glean different patterns or produce specialized reports. This is where OLAP and Cubes enter the picture.

Question: What is the difference between a cube and a square or rectangle?
Answer: Multidimensionality.

That is a long and confusing word. It reminds me of my favorite movie growing up – “Back To The Future”:
Doc:”Marty! You’re not thinking fourth-dimensionally!”
Marty:”Yeah, right, I have a real problem with that.”

Even programmers have that problem as well. That makes cubism seem daunting. It is for that reason cubism can be explained using good old fashioned 3-dimensionality. A Relational Database, like excel spreadsheets, consists of 2 dimensions, rows and columns. A cube is a square drawn 3-dimensionally. Thus, it is a good starting point to move beyond the scope of the conventional 2-dimensions.

Data mining architectures, on the other hand, are utilized for speed of data analysis. In order to pull off this task, data is stored in a Data Warehouse where data is de-normalized via a dimension-based model, a Cube.
To enhance the speed data retrieval, data is stored in a number of different ways in their most granular forms. These storage mechanisms are called Aggregates.

A cube is a data structure whose design allows for speedy analysis of information. Besides speed, cubes are capable of manipulating and analyzing data from many different perspectives, or Pivots. The way cubes can organize data overcomes the limitations of relational databases.

In this blog I plan on describing cubes in the context of OLAP (On Line Analytical Programming) databases; as well as how and when to use them. I will define all the terms needed to understand cubes by explaining:
• Dimensions
• Measures
• Members
• Hierarchies
• Data sources
• Pivots
• MDX

Once we have an OLAP Cube Database up and running, we will learn a pseudo-SQL like language designed to glean data from multiple pivots, called MDX.

The big question is wether the effort it takes to write tests is balanced out by the benefits they provide. It has been shown in a number of cases that for medium to large projects with non-trivial codebases, Unit tests do improve both development productivity and product quality. See Steve Sanderson’s blog post for a good costs/benefit analysis.

The main benefits offered by Unit tests are that they help you to:

• design code while you’re writing it
• verify that your implementation actually does what you intended it to do

As a consequence Unit testss make it possible to refactor safely and add a layer of documentation to your code, showing how it is intended to be used.

Before delving deeper into the topic, let’s define what a Unit Test is. Roy Osherove provides the following definition:

A unit test is an automated piece of code that invokes the method or class being tested and then checks some assumptions about the logical behavior of that method or class.

Unit Test Frameworks

There are a number of frameworks which facilitate Unit Testing capabilities for .Net. One of the most popular ones is NUnit, an open source project ported from Java’s JUnit.

In NUnit, tests are written as functions which are decorated with attributes to mark them as tests.
A typical test suite would look like this:

using System;
using NUnit.Framework;

namespace MyProject.Tests
{
    [TestFixture]
    public class CalculatorTests
    {
        private MyProject.ICalculator myCalculator;

        [SetUp]
        public void Init()
        {
            // code that will be called before each Test case.
            myCalculator = new MyProject.Calculator();
        }

        [TearDown]
        public void Clean()
        {
            // code that will be called after each Test case
            myCalculator = null;
        }

        [Test]
        public void Add_TwoIntegers_ReturnsSum()
        {
            int num1 = 3;
            int num2 = 4;
            int sum = myCalculater.Add(3,4);
            Assert.AreEqual(7, sum);
        }
    }
}

The NUnit client can detect these functions, run the tests and show the results:

Alternatively, you can use Testdriven.net – a unit testing add-in for Visual Studio which allows running tests from within Visual Studio with a single-click:

Unit Test Guidelines
An important aspect is the naming convention for test objects. Roy Osherove suggests the following rules dependent on the object under test:

• Project: [ProjectUnderTest].Tests
• Class: [ClassName]Tests
• Method: [MethodName]_[StateUnderTest]_[ExpectedBehavior]

As there are guidelines for writing good code, there are criterias for good unit tests:

• Repeatable: You must be able to measure an expected outcome reliably for known inputs.
• Independent of other tests: Any subset of tests should be able to run in any order w/o affecting the outcome.
• Easy to write: If it takes a lot of work to set up the inputs to a test, you aren’t going to recoup your investment in writing that test. Difficulty in writing a test usually points to a flaw in design: time to refactor.
• Easy to understand: Ideally, the automated tests that you write should also serve as a useful form of design and requirements documentation.
• Fast: Slow-running tests will retard productivity.

In order to avoid interdependencies between tests, it is important that no state is shared between tests.

Design for Testability
According to Jeremy Miller, “Testability is the quality of a software design that allows for automated testing in a cost-effective manner“.

The two biggest problem with writing testable code are:

• Side effects: a method which, in addition to producing a value, also modifies some state
• Dependencies: objects in your system that your code interacts with. These can be other business objects or external dependencies s.a. filesystems, threads, memory, time, etc.

Side-Effect free functions
It is almost trivial to test a function when all you have to do is inspect it’s return value.
Side-effect free functions are the cornerstone of functional programming, where side effects are not allowed (unless through monads).
In classic OOP though, we are encouraged to write methods which modify the internal state of an object. Writing OO code while avoiding side effects is a very important concept in Domain Driven Design.

There are several patterns on how to avoid side effects, one of which is making objects immutable – meaning that once initialized, the object cannot be changed. This may sound strange, but consider the String class in .Net, which is immutable. Eric Lippert, a leading designer and implementor of the C# language and .NET Framework wrote, that in his opinion:

“Immutable data structures are the way of the future in C#. It is much easier to reason about a data structure if you know that it will never change.”

In fact, he wrote an entire series of posts on immutability.

Dependencies
While side effects make unit testing harder, because you have to think about changes in your object’s state after you call a method, an even uglier problem are external dependencies.

If a method accesses the database or a configuration file, then your tests are not repeatable, unless you initialize the state of the DB or the file on every test run.

A much better approach is to “fake” your dependency so it behaves in a predictable manner which is under your control. In order to fake a dependency, the test routine must be able to switch the original object with a fake implementation.

Consider the following implementations of class House:

//Implementation 1: Impossible to access the variable
class House
{
    private Bedroom bedroom;

    public House()
    {
        bedroom = new Bedroom();
    }
    //more methods...
}

//Implementation 2: Possible to access the variable on object creation (via the constructor) but difficult to provide an alternative implementation
class House
{
    private Bedroom bedroom;

    public House(Bedroom b)
    {
        bedroom = b;
    }
    //more methods...
}

//Implementation 3: Possible to exchange the variable's implementation, since it is exposed by an Interface
class House
{
    private IBedroom bedroom;

    public House(IBedroom b)
    {
        bedroom = b;
    }
    //more methods...
}

In order to test House no. 3 we could create a fake object FakeBedroom which implements the interface IBedroom and lets us test the House w/o it’s dependency on Bedroom’s implementation. Instead of passing the dependency in via the constructor, we could expose it as a public Property and set it after the object is initialized. Both methods are ways to perform Dependency Injection. Ideally all of your important dependencies should be made injectable and managed via a Dependency Injection (DI) Framework s.a. Spring.Net or Castle Windsor.

Coming back to fake objects, we usually distinguish between two types:

• Stubs: A stub is a controllable replacement for an existing dependency (or collaborator) in the system. By using a stub, you can test your code without dealing with the dependency directly.
• Mocks: A mock is a fake object which verifies whether the object under test interacted as expected with the fake object. A mock is much like a stub, except that a mock additionally saves the history of communication, which will later be verified.

RhinoMocks
Before we will look at an example, I want to address an important point: While it is possible to create Stubs and Mocks manually, it is very tedious to do so and is generally not worth the effort. Instead there are a number of frameworks available which let you create Mocks and Stubs on the fly. The most widely used mocking framework in .Net is RhinoMocks by Oren Eini otherwise known as Ayende Rahien (Besides being the author of RhinoMocks, Oren is an active contributor of the NHibernate and Castle projects and the author of one of the most popular .Net blogs: http://ayende.com/Blog/).

In RhinoMocks fake objects can be used the following way:

1. The framework creates the fake object which impelements a given interface
2. The expected behavior of the fake object is “recorded”
3. The fake object is injected into the object-to-test
4. The method-to-test is called
5. During the call the recorded behvior of the fake object is “played back” according to the interaction with the object-to-test
6. The framework verifies that the all the expectations are fulfilled

Example: The following example (borrowed from Roy Osherove) shows a LogAnalyzer which depends on a WebService for error logging and on an Email Service for Notification. The Analyze() method checks if the filename is too short and if so, logs the error by calling the WebService. If that call fails, an email-notification is sent via the EmailService:

public class LogAnalyzer
{
    public IWebService Service { get; set; }
    public IEmailService Email { get; set; }

    public void Analyze(string fileName)
    {
        if ( fileName.Length < 8 )
        {
            try
            {
                service.LogError("Filename too short:" + fileName);
            }
            catch (Exception e)
            {
                email.SendEmail("a", "subject", e.Message);
            }
        }
    }
}

A test of the Analyze method using NUnit and RhinoMocks could look something like this:

[Test]
public void Analyze_WebServiceThrows_SendsEmail()
{
    MockRepository mocks = new MockRepository();
    IWebService stubService = mocks.Stub();
    IEmailService mockEmail = mocks.StrictMock();

    using(mocks.Record())
    {
        //Set up stub behavior:
        // if LogError is called...
        stubService.LogError("whatever");
        // ...then regardless of the input...
        LastCall.Constraints(Is.Anything());
        // ...throw an ecxeption!
        LastCall.Throw(new Exception("fake exception"));

        //Set up expected mock behavior:
        mockEmail.SendEmail("a","subject","fake exception");
    }

    //initialize LogAnalyzer
    LogAnalyzer log = new LogAnalyzer();

    //inject fake WebService and EmailService objects
    log.Service = stubService;
    log.Email = mockEmail;

    //call the method we want to test
    string tooShortFileName = "abc.ext";
    log.Analyze(tooShortFileName);

    //verify that all expectations on the mock object are fulfilled
    mocks.VerifyAll();
}

A thorough coverage of RhinoMocks is beyond the scope of this article, the aim of which was to briefly present a current approach to Unit Testing in .Net.

There are many excellent .Net frameworks (e.g. the built-in testing framework of Visual Studio 2010), patterns and principles (e.g. Test Driven Design) regarding unit testing in particular and software testing in general, which can greatly contribute to the quality of your code and the efficiency of your development process.

Conclusion

• In most cases Unit Tests improve code quality and productivity
• Design Unit Tests to be repeatable, fast and independent from each other
• Design code for testability by reducing side-effects and managing your dependencies via a dependency injection framework
• Make use of testing frameworks, s.a. NUnit, Testdriven.Net and RhinoMocks to make writing unit tests feasible

Resources

• Roy Osherove’s book: “The Art of Unit Testing with Examples in .NET”
• Jeremy Miller’s article “Design for Testability”
• Misko Hevery has published an excellent Guide about how the folks at Google design their code for testability

Manuel Korn

Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts. 

A thorough presentation of the principles, tenets and practices of DDD are outside the scope of this article. Instead, I would like to focus on one specific concept that Evans forgot to include when he wrote the book five years ago and which he today presents as one of the fundamental building blocks for successful DDD: Domain Events.

Captures the memory of something interesting which affects the domain

1. Publisher / Subscriber instead of RPC
   Instead of directly invoking all the consequences of a change in the system, an event is raised which can be handled by whomever is interested in it.
2. Event Sourcing instead of mutable state
   Instead of altering the state of the system directly as soon as something happens, the change is reflected in the history (or log) of events. You can think of it as an incremental backup: Only the most recent changes must be saved because we rely on an existing record of all previous changes.  This is known as Event Sourcing and I do not want to go into it further.

Now, event-driven programming is hardly new – most UI Frameworks s.a. ASP.Net and Winforms are based on exposing events on controls. The crux of the Domain-Event pattern is that not only do you use events in UI scenarios but in your core business model. An example should shed light on the differences in approach:

Given an Ecommerce application, the following functional requirements are given:

When a user wires money into his account:

• his credit card must be validated and charged
• his balance must be updated
• his status must be updated (maybe he became a preferred customer)
• he needs to be notified via email
• the event needs to be logged

In a traditional programming model, we would end up writing something like this:

DepositMoney(User u, double amount, currency curr)
{
    ccInfo cc = Repository.GetCcInfo(u.UserID);

    if( CreditCard.Authorize(cc, amount, curr) )
    {
        CreditCard.Settle(cc, amount, curr);
        Payment.Add(u.UserID, amount, curr);
        Notification.SendPaymentConfirmationMsg(u.UserID, amount, curr);
        Log.PlayerPayment(u.UserID, amount, curr);

        if( Account.IsEligibleForUpgrade(u.UserID) )
        {
            UpgradeInfo upg = Account.Upgrade(u.UserID);
            Notification.SendCustomerUpgradeMsg(upg);
            Log.CustomerUpgrade(u.UserID, upg);
        }
    }
    else
    {
        Notification.SendCcRefusedMsg(u, cc);
        Log.CcRefusal(u.UserID, cc, amount, curr);
    }
}

The above example is obviously incomplete but it shows how fast we can find ourselves in a dependency hell, i.e. within a single method we reference six different modules (Repository, CreditCard, Payment, Notification, Log, Account) which ideally should not have any knowledge of each other.

Also the above design raises all kinds of inconvenient dilemmas, for example: the Log is always called after we send a Notification. Maybe we should include logging in the Notification methods? This would definitely reduce the chances of forgetting to log an event, but it would also create a direct dependency between the two unrelated modules and thus negate the principles of maximizing cohesion and separation of concerns.

It seems that either way, we’ll end up with messy code which will be hard to maintain – the first step towards the dreaded Big Ball of Mud architecture. 

How can Domain Events help?

With Domain Events the above method simply raises a DepositRequestedEvent, which includes the references to the user, amount and currency. Other modules subscribe to this type of event. In our case, a PaymentService subscribes to the DepositRequestedEvent, and upon observing such an event authorizes and settles the credit card, updates the balance and raises in turn a PaymentAddedEvent or a CcRefusedEvent. These events are handled independently by an AccountService, a NotificationService and an LogService. The AccountService may raise a CustomerUpgradedEvent which is handled by NotificationService and LogService. Whenever something important happens in the system another event is raised. 

This way we can drastically reduce the amount of interdependencies because modules do not call each other directly. Since this is an asynchronous messaging model our system becomes more scalable and may even deliver better performance because tasks can be processed in parallel.

Obviously this kind of architecture demands a sophisticated subscriber/publisher infrastructure for managing the message streams and event subscriptions. In this article I want to briefly present two such frameworks: 

• Udi Dahan’s NServiceBus
• .Net 4.0 Reactive Framework (RxFramework)

NServiceBus is a one-way asynchronous queued messaging platform which was developed with the following focus in mind:

• Inherent Publisher / Subscriber support (each message sent can be viewed as an event raised)
• Developer friendly (Painless installation and usage)
• Reliability and Scalability (NServiceBus is built upon MSMQ which facilitates persisted and thus reliable messaging)
• Support for long-running workflows (or “Sagas” as they are called in NServiceBus terminology)
• Extensibility

One of the great features of NServiceBus is that events are defined as classes which implement one or more interfaces. A subscriber subscribes to an Event via its Interface. That means that different events can be handled by the same subscription as long as they implement a common interface (e.g. IEmailNotification or ILoggable).

As a consequence, the decision whether an event is handled or not depends neither on the subscriber (who handles all events which implement a certain interface) nor on the publisher (who only knows the type of the event, not all the implemented interfaces) but on the event itself. This adds a level of cohesion to all the components involved which is very difficult to achieve in the classic approach above. To quote Udi Dahan:

[Domain Events based architecture] complies with the Single Responsibility Principle, so the business requirement which states that when a customer becomes preferred, they should be sent an email belongs somewhere else.

Notice that the key word in the requirement – “when”.

Any time you see that word in relation to your domain, consider modeling it as a domain event.

For an excellent discussion of how NServiceBus can assist in developing a domain events based application, read Udi Dahan’s article. In case you want to listen to a one-hour talk of Udi about NServiceBus architecture, check out this podcast.

As opposed to NServiceBus the RxFramework does not provide a reliable messaging solution. Instead it attempts to change the way we as programmers deal with sequentially arriving input. Until now the dominating pattern regarding sequential input was the IEnumerable interface and the “yield” keyword in C#. Since the advent of LINQ and the deferred execution mechanism, this Design Pattern has received a lot of attention. The idea is very simple: Instead of looking at the complete sequence of inputs up front, we only retrieve one member at a time.

The RxFramework takes this idea one step further and postulates: Instead of “pulling” each member of the sequence by explicitly asking for it, let’s subscribe to the sequence and whenever the next member “appears”, we will be notified. In this model, a stream of events is treated as data which can be filtered and processed very similarly (in fact identically) to the way we are used to processing any list or sequence of regular objects. Wes Dyer has written an excellent introduction to the RXFramework, which clarifies this point and shows how it makes .Net Events more manageable.

We can utilize this ability to implement the event-domain pattern. In fact, Mike Chaliy presents a nice example of how to implement a money transfer scenario (very similar to the one above) as domain events via the RxFramework.

Conclusion

Domain Events are a recognized architectural pattern which is gaining more and more popularity among the designers of highly scalable and robust systems. The reasons for its rising popularity are threefold:

• As Applications become more complex, the need for better code organization increases
• The need for highly scalable applications grows steadily
• The availability of supporting Frameworks enable developers to implement a Domain Events architecture without having to develop their own messaging solutions

Two frameworks were presented which facilitate two radically different approaches to Domain Event based architecture:

• NServiceBus: a platform for reliable, asynchronous, one-way messaging and long running workflows
• RxFramework: treats a stream of events like data which can be filtered and manipulated easily

Manuel Korn

After working at db@net  for over two and a half years, I feel that something very exciting is happening these days: the shift towards collaborative knowledge reuse!

Until now, I’ve had the opportunity to learn tons of new and cool stuff at db@net, but I wasn’t able to share these experiences and receive constructive feedback in a structured manner from all the other smart people around.

This is about to change with the opening of this and other technical blogs which constitute a platform for the exchange of questions, ideas and experiences of our corporate programming community.

I am particularly excited about the .Net blog because of db@net’s proven track record designing and implementing great .Net apps.

The articles presented and discussed here shall cover a very wide range of topics as long as they are remotely connected to .Net programming:

• Insights gathered while designing, developing, deploying or maintaining .Net apps
• Your latest brilliant piece of code you want everyone to be jealous of
• New and cool technologies and frameworks
• Design and architectural patterns
• Book and article reviews
• Coding puzzles

I am absolutely convinced that this blog has great potential to contribute to every member of our team and I am looking forward to being a part of it.

Manuel Korn

This site is not an advertisment site although in nowerdays everything that is published over the net may be seen and even measured as part of advertisment campaigns. So let me state that this was not our intention – at least.

Although I actively experienced the break-through of the internet generation – yes, indeed I am that old – and had probably a certain impact on my near professional environment I have the feeling as if I would sit in a new car, nylon still on the seats and a fresh smell of “new” in the air …

This is my first blog – This is what I meant to say

My main intention with this blog is to analyse and discuss all aspects related to business continuity and eventually propose some to-do’s or not to-do’s. Important to note that business continuity is only partially a technological topic. Respectively I would claim that the goal of business continuity – as it’s name suggests – is solely business-oriented. Having said that it is definitely true that many of the implementations to seek business continuity are mainly based on mostly complex technological solutions. This fact – although – should not irritate us: Technology is only the way to achieve the business goal!

Let us make a fast search in the net to find a definition for business continuity. The “great thing” about the net is that you can probably always find a definition that fits your personal view – and so I did (Wikipedia: Business Continuity):

„Business continuity is the activity performed by an organization to ensure that critical business functions will be available to customers, suppliers, regulators, and other entities that must have access to those functions. These activities include many daily chores such as project management, system backups, change control, and help desk. Business Continuity is not something implemented at the time of a disaster; Business Continuity refers to those activities performed daily to maintain service, consistency, and recoverability.”

In the coming articles we will explain several components of business continuity. We definitely will discuss some “real world” examples to better illustrate concepts. Important for a fruitful discussion is of course your participation in it. We will take seriously every of your comments, being constructively, critically or only questioning.

I am sure that this topic is as important as interesting to all of us and I am looking forward to discussing it with you.

Yours

Ariel