While I tend to put search in the query camp in the when keeping the responsibility of commands and queries separate, and often recommend that those queries be done without messaging, there are certain types of search where messaging does make sense.

In this post, I’ll describe certain properties of the problem domain that make messaging a good candidate for a solution.

Searching is besides the point – Finding is what it’s all about

Remember that search is only a means to an end in the eyes of the user – they want to find something. One of the difficulties we users have is expressing what we want to find in ways that machines can understand.

In thinking about how we build systems to interact with users, we need to take this fuzziness into account. The more data that we have, the less homogeneous it is, the harder this problem becomes.

When talking about speed, while users are sensitive to the technical interactivity, the thing that matters most is the total time it takes for them to find what they want. If the result of each search screen pops up in 100ms, but the user hasn’t found what they’re looking for after clicking through 20 screens, the search function is ultimately broken.

Notice that the finding process isn’t perceived as “immediate” in the eyes of the user – the evaluation they do in their heads of the search results is as much a part of finding as the search itself.

Also, if the user needs to refine their search terms in order to find what they want, we’re now talking about a multi-request/multi-response process. There is nothing in the problem domain which indicates that finding is inherently request/response.

Relationships in the data

When bringing back data as the result of a search, what we’re saying is that there is a property which is the same across the result elements. But there may be more than one such property. For example, if we search for “blue” on Google Images, we get back pictures of the sky, birds, flowers, and more. Obvious so far – but let’s exploit the obvious a bit.

When the user sees that too many irrelevant results come back, they’ll want to refine their search. One way they can do that is to perform a new search and put in a more specific search phrase – like “blue sky”. Another way is for them to indicate this is by selecting an image and saying “not like this” or “more of these”. Then we can use the additional properties we know about those images to further refine the result group – either adding more images of one kind, or removing images of another.

Here’s something else that’s obvious:

Users often click or change their search before the entire result screen is shown.

It’s beginning to sound like users are already interacting with search in an asynchronous manner. What if we actually designed a system that played to that kind of interaction model?

Data-space partitioning

Once we accept the fact that the user is willing to have more results appear in increments, we can talk about having multiple servers processing the search in parallel. For large data spaces, it is unlikely for us to be able to store all the required meta data for search on one server anyway.

All we really need is a way to index these independent result-sets so that the user can access them. This can be done simply by allocating a GUID/UUID for the search request and storing the result-sets along with that ID.

Browser interaction

When the browser calls a server with the search request the first time, that server allocates an ID to that request, returns a URL containing that ID to the browser, and publishes an event containing the search term and the ID. Each of our processing nodes is subscribed to that event, performs the search on its part of the data-space, and writes its results (likely to a distributed cache) along with that ID.

The browser polls the above URL, which queries the cache (give me everything with this ID), and the browser sees which resources have been added since the last time it polled, and shows them to the user.

If the user clicks “more of these”, that initiates a new search request to the server, which follows the same pattern as before, just that the system is able to pull more relevant information. When implementing “not like this”, this performs a similar search but, instead of adding to the list of items shown, we’re removing items from the list shown based on the response from the server.

In this kind of user-system interaction model, having the user page through the result set doesn’t make very much sense as we’re not capturing the intent of the user, which is “you’re not showing me what I want”. By making it easy for the user to fine tune the result set, we get them closer to finding what they want. By performing work in parallel in a non-blocking manner on smaller sets of data, we greatly decrease the “time to first byte” as well as the time when the user can refine their search.

But Google doesn’t work like that

I know that this isn’t like the search UI we’ve all grown used to.

But then again, the search that you’re providing your users is more specific – not just pages on the web. If you’re a retailer allowing your users to search for a gift, this kind of “more like this, less like that” model is how users would interact with a real sales-person when shopping in a store. Why not model your system after the ways that people behave in the real world?

In closing

If we were to try to make use of messaging underneath “classical” search interaction models, it probably wouldn’t have been the greatest fit. If all we’re doing at a logical level is blocking RPC, then messaging would probably make the system slower. The real power that you get from messaging is being able to technically do things in parallel – that’s how it makes things faster. If you can find ways to see that parallelism in your problem domain, not only will messaging make sense technically – it will really be the only way to build that kind of system.

Learning how to disconnect from seeing the world through the RPC-tinted glasses of our technical past takes time. Focusing on the problem domain, seeing it from the user’s perspective without any technical constraints – that’s the key to finding elegant solutions. More often than not, you’ll see that the real world is non-blocking and parallel, and then you’ll be able to make the best use of messaging and other related patterns.

What are your thought? Post a comment and let me know.

My latest article has been published in issue 21 of the Microsoft Architecture Journal:

EDA: SOA Through The Looking Glass

Please leave questions and comments here.

There’s this belief that if we just reused more code, everything would be better.

Some even go so far as saying that the whole point of object-orientation was reuse – it wasn’t, encapsulation was the big thing. After that component-orientation was the thing that was supposed to make reuse happen. Apparently that didn’t pan out so well either because here we are now pinning our reuseful hopes on service-orientation.

Entire books of patterns have been written on how to achieve reuse with the orientation of the day.
Services have been classified every which way in trying to achieve this, from entity services and activity services, through process services and orchestration services. Composing services has been touted as the key to reusing, and creating reusable services.

I might as well let you in on the dirty-little secret:

Reuse is a fallacy

Before running too far ahead, let’s go back to what the actual goal of reuse was: getting done faster.

That’s it.

It’s a fine goal to have.

And here’s how reuse fits in to the picture:

If we were to write all the code of a system, we’d write a certain amount of code.
If we could reuse some code from somewhere else that was written before, we could write less code.
The more code we can reuse, the less code we write.
The less code we write, the sooner we’ll be done!

However, the above logical progression is based on another couple of fallacies:

Fallacy: All code takes the same amount of time to write

Fallacy: Writing code is the primary activity in getting a system done

Anyone who’s actually written some code that’s gone into production knows this.

There’s the time it takes us to understand what the system should do.
Multiply that by the time it takes the users to understand what the system should do
Then there’s the integrating that code with all the other code, databases, configuration, web services, etc.
Debugging. Deploying. Debugging. Rebugging. Meetings. Etc.

Writing code is actually the least of our worries.
We actually spend less time writing code than…

Rebugging code

Also known as bug regressions.

This is where we fix one piece of code, and in the process break another piece of code.
It’s not like we do it on purpose. It’s all those dependencies between the various bits of code.
The more dependencies there are, the more likely something’s gonna break.
Especially when we have all sorts of hidden dependencies,
like when other code uses stuff we put in the database without asking us what it means,
or, heaven forbid, changing it without telling us.

These debugging/rebugging cycles can make stabilizing a system take a long time.

So, how does reuse help/hinder with that?

Here’s how:

Dependencies multiply by reuse

It’s to be expected. If you wrote the code all in one place, there are no dependencies. By reusing code, you’ve created a dependency. The more you reuse, the more dependencies you have. The more dependencies, the more rebugging.

Of course, we need to keep in mind the difference between…

Reuse & Use

Your code uses the runtime API (JDK, .NET BCL, etc).
Likewise other frameworks like (N)Hibernate, Spring, WCF, etc.

Reuse happens when you extend and override existing behaviors within other code.
This is most often done by inheritance in OO languages.

Interestingly enough, by the above generally accepted definition, most web services “reuse” is actually really use.

Let’s take a look at the characteristics of the code we’re using and reusing to see where we get the greatest value:

The value of (re)use

If we were to (re)use a piece of code in only one part of our system, it would be safe to say that we would get less value than if we could (re)use it in more places. For example, we could say that for many web applications, the web framework we use provides more value than a given encryption algorithm that we may use in only a few places.

So, what characterizes the code we use in many places?

Well, it’s very generic.

Actually, the more generic a piece of code, the less likely it is that we’ll be changing something in it when fixing a bug in the system.

That’s important.

However, when looking at the kind of code we reuse, and the reasons around it, we tend to see very non-generic code – something that deals with the domain-specific behaviors of the system. Thus, the likelihood of a bug fix needing to touch that code is higher than in the generic/use-not-reuse case, often much higher.

How it all fits together

Goal: Getting done faster
Via: Spending less time debugging/rebugging/stabilizing
Via: Having less dependencies reasonably requiring a bug fix to touch the dependent side
Via: Not reusing non-generic code

This doesn’t mean you shouldn’t use generic code / frameworks where applicable – absolutely, you should.
Just watch the number of kind of dependencies you introduce.

Back to services

So, if we follow the above advice with services, we wouldn’t want domain specific services reusing each other.
If we could get away with it, we probably wouldn’t even want them using each other either.

As use and reuse go down, we can see that service autonomy goes up. And vice-versa.
Luckily, we have service interaction mechanisms from Event-Driven Architecture that enable use without breaking autonomy.
Autonomy is actually very similar to the principle of encapsulation that drove object-orientation in the first place.
Interesting, isn’t it?

In summary

We all want to get done faster.

Way back when, someone told us reuse was the way to do that.

They were wrong.

Reuse may make sense in the most tightly coupled pieces of code you have, but not very much anywhere else.

When designing services in your SOA, stay away from reuse, and minimize use (with EDA patterns).

The next time someone pulls the “reuse excuse”, you’ll be ready.

Further Reading

• Additional logic required for service autonomy
• Self-contained events & SOA
• Autonomous Services and Enterprise Entity Aggregation [MS Architecture Journal]
• Does SOA mean the end of OO? [Podcast]

The common e-commerce example

We accept orders, bill the customer, and then ship them the product.

Fairly straight-forward.

Since each part of that process can be quite complex, let’s have each step be handled by a service:

Sales, Billing, and Shipping. Each of these services will publish an event when it’s done its part. Sales will publish OrderAccepted containing all the order information – order Id, customer Id, products, quantities, etc. Billing will publish CustomerBilledForOrder containing the customer Id, order Id, etc. And Shipping will publish OrderShippedToCustomer with its data.

So far, so good. EDA and SOA seem to be providing us some value.

Where’s the saga?

Well, let’s consider the behavior of the Shipping service. It shouldn’t ship the order to the customer until it has received the CustomerBilledForOrder event as well as the OrderAccepted event. In other words, Shipping needs to hold on to the state that came in the first event until the second event comes in. And this is exactly what sagas are for.

Let’s take a look at the saga code that implements this. In order to simplify the sample a bit, I’ll be omitting the product quantities.

   1:      public class ShippingSaga : Saga<ShippingSagaData>,

   2:          ISagaStartedBy<OrderAccepted>,

   3:          ISagaStartedBy<CustomerBilledForOrder>

   4:      {

   5:          public void Handle(OrderAccepted message)

   6:          {

   7:              this.Data.ProductIdsInOrder = message.ProductIdsInOrder;

   8:          }

   9:   

  10:          public void Handle(CustomerBilledForOrder message)

  11:          {

  12:               this.Bus.Send<ShipOrderToCustomer>(

  13:                  (m =>

  14:                  {

  15:                      m.CustomerId = message.CustomerId;

  16:                      m.OrderId = message.OrderId;

  17:                      m.ProductIdsInOrder = this.Data.ProductIdsInOrder;

  18:                  }

  19:                  ));

  20:   

  21:              this.MarkAsComplete();

  22:          }

  23:   

  24:          public override void Timeout(object state)

  25:          {

  26:              

  27:          }

  28:      }

First of all, this looks fairly simple and straightforward, which is good.

It’s also wrong, which is not so good.

One problem we have here is that events may arrive out of order – first CustomerBilledForOrder, and only then OrderAccepted. What would happen in the above saga in that case? Well, we wouldn’t end up shipping the products to the customer, and customers tend not to like that (for some reason).

There’s also another problem here. See if you can spot it as I go through the explanation of ISagaStartedBy<T>.

Saga start up and correlation

The “ISagaStartedBy<T>” that is implemented for both messages indicates to the infrastructure (NServiceBus) that when a message of that type arrives, if an existing saga instance cannot be found, that a new instance should be started up. Makes sense, doesn’t it? For a given order, when the OrderAccepted event arrives first, Shipping doesn’t currently have any sagas handling it, so it starts up a new one. After that, when the CustomerBilledForOrder event arrives for that same order, the event should be handled by the saga instance that handled the first event – not by a new one.

I’ll repeat the important part: “the event should be handled by the saga instance that handled the first event”.

Since the only information we stored in the saga was the list of products, how would we be able to look up that saga instance when the next event came in containing an order Id, but no saga Id?

OK, so we need to store the order Id from the first event so that when the second event comes along we’ll be able to find the saga based on that order Id. Not too complicated, but something to keep in mind.

Let’s look at the updated code:

   1:      public class ShippingSaga : Saga<ShippingSagaData>,

   2:          ISagaStartedBy<OrderAccepted>,

   3:          ISagaStartedBy<CustomerBilledForOrder>

   4:      {

   5:          public void Handle(CustomerBilledForOrder message)

   6:          {

   7:              this.Data.CustomerHasBeenBilled = true;

   8:   

   9:              this.Data.CustomerId = message.CustomerId;

  10:              this.Data.OrderId = message.OrderId;

  11:   

  12:              this.CompleteIfPossible();

  13:          }

  14:   

  15:          public void Handle(OrderAccepted message)

  16:          {

  17:              this.Data.ProductIdsInOrder = message.ProductIdsInOrder;

  18:   

  19:              this.Data.CustomerId = message.CustomerId;

  20:              this.Data.OrderId = message.OrderId;

  21:   

  22:              this.CompleteIfPossible();

  23:          }

  24:   

  25:          private void CompleteIfPossible()

  26:          {

  27:              if (this.Data.ProductIdsInOrder != null && this.Data.CustomerHasBeenBilled)

  28:              {

  29:                  this.Bus.Send<ShipOrderToCustomer>(

  30:                     (m =>

  31:                     {

  32:                         m.CustomerId = this.Data.CustomerId;

  33:                         m.OrderId = this.Data.OrderId;

  34:                         m.ProductIdsInOrder = this.Data.ProductIdsInOrder;

  35:                     }

  36:                     ));

  37:                  this.MarkAsComplete();

  38:              }

  39:          }

  40:      }

And that brings us to…

Saga persistence

We already saw why Shipping needs to be able to look up its internal sagas using data from the events, but what that means is that simple blob-type persistence of those sagas is out. NServiceBus comes with an NHibernate-based saga persister for exactly this reason, though any persistence mechanism which allows you to query on something other than saga Id would work just as well.

Let’s take a quick look at the saga data that we’ll be storing and see how simple it is:

   1:      public class ShippingSagaData : ISagaEntity

   2:      {

   3:          public virtual Guid Id { get; set; }

   4:          public virtual string Originator { get; set; }

   5:          public virtual Guid OrderId { get; set; }

   6:          public virtual Guid CustomerId { get; set; }

   7:          public virtual List<Guid> ProductIdsInOrder { get; set; }

   8:          public virtual bool CustomerHasBeenBilled { get; set; }

   9:      }

You might have noticed the “Originator” property in there and wondered what it is for. First of all, the ISagaEntity interface requires the two properties Id and Originator. Originator is used to store the return address of the message that started the saga. Id is for what you think it’s for. In this saga, we don’t need to send any messages back to whoever started the saga, but in many others we do. In those cases, we’ll often be handling a message from some other endpoint when we want to possibly report some status back to the client that started the process. By storing that client’s address the first time, we can then “ReplyToOriginator” at any point in the process.

The manufacturing sample that comes with NServiceBus shows how this works.

Saga Lookup

Earlier, we saw the need to search for sagas based on order Id. The way to hook into the infrastructure and perform these lookups is by implementing “IFindSagas<T>.Using<M>” where T is the type of the saga data and M is the type of message. In our example, doing this using NHibernate would look like this:

   1:      public class ShippingSagaFinder : 

   2:          IFindSagas<ShippingSagaData>.Using<OrderAccepted>,

   3:          IFindSagas<ShippingSagaData>.Using<CustomerBilledForOrder>

   4:      {

   5:          public ShippingSagaData FindBy(CustomerBilledForOrder message)

   6:          {

   7:              return FindBy(message.OrderId)

   8:          }

   9:   

  10:          public ShippingSagaData FindBy(OrderAccepted message)

  11:          {

  12:              return FindBy(message.OrderId)

  13:          }

  14:   

  15:          private ShippingSagaData FindBy(Guid orderId)

  16:          {

  17:              return sessionFactory.GetCurrentSession().CreateCriteria(typeof(ShippingSagaData))

  18:                  .Add(Expression.Eq("OrderId", orderId))

  19:                  .UniqueResult<ShippingSagaData>();

  20:          }

  21:   

  22:          private ISessionFactory sessionFactory;

  23:   

  24:          public virtual ISessionFactory SessionFactory

  25:          {

  26:              get { return sessionFactory; }

  27:              set { sessionFactory = value; }

  28:          }

  29:      }

For a performance boost, we’d probably index our saga data by order Id.

On concurrency

Another important note is that for this saga, if both messages were handled in parallel on different machines, the saga could get stuck. The persistence mechanism here needs to prevent this. When using NHibernate over a database with the appropriate isolation level (Repeatable Read – the default in NServiceBus), this “just works”. If/When implementing your own saga persistence mechanism, it is important to understand the kind of concurrency your business logic can live with.

Take a look at Ayende’s example for mobile phone billing to get a feeling for what that’s like.

Summary

In almost any event-driven architecture, you’ll have services correlating multiple events in order to make decisions. The saga pattern is a great fit there, and not at all difficult to implement. You do need to take into account that events may arrive out of order and implement the saga logic accordingly, but it’s really not that big a deal. Do take the time to think through what data will need to be stored in order for the saga to be fault-tolerant, as well as a persistence mechanism that will allow you to look up that data based on event data.

If you feel like giving this approach a try, but don’t have an environment handy for this, download NServiceBus and take a look at the samples. It’s really quick and easy to get set up.

Greg Young asserts:

“I believe that this shows there to be a rather negligible cost associated with the use of such a model. There is however a small cost, this cost however I believe only exists when one looks at the system in isolation.”

Ayende adds his perspective:

“The cost of messaging, and a very real one, comes when you need to understand the system. In a system where message exchange is the form of communication, it can be significantly harder to understand what is going on.”

Of course, both these intelligent fellows are right. The reason for the apparent disparity in viewpoints has to do with which part of the following graph you look at. Ayende zooms in on the left side:

As systems get larger, though, the only way to understand them is by working at higher levels of abstraction. That’s where messaging really shines, as the incremental complexity remains the same by maintaining the same modularity as before:

In Ayende’s post, he follows the design I described a while back on using messaging for user management and login for a high-scale web scenario. In his comments, he agrees with the above stating:

“I certainly think that a similar solution using RPC would be much more complex and likely more brittle.”

I feel quite conservative in saying the most enterprise solutions fall on the right side of the intersection in the graph.

That being said, don’t underestimate the learning curve developers go through with messaging. While the mechanics are similar, the mindset is very different. Think about it like this:

You’ve driven a car for years in the US. It’s practically second nature. Then you fly to the UK, rent a car, and all of a sudden, your brain is in meltdown. (or vice versa for those going from the UK to the US)

Summary

If you are going down the messaging route, please be aware that there are shades of gray there as well. You don’t have to implement your user management and login the way I outlined in my post if you don’t require such high levels of scalability, but even lower levels of scalability can benefit from messaging.

Just as there isn’t a single correct design for non-messaging solutions, the same is true for those using messaging. Finding the right balance is tricky, and critical.

When the code is simple in every part of the system, and the asynchronous interactions are what provide for the necessary complexity the problem domain requires, that’s when you know you’ve got it just right.

The question of how web-based (or 3rd party) consumers can work with pub/sub based services comes up a lot.

Many developers are used to implementing web services exposing methods on them like GetAllCustomers.

When moving to pub/sub and other more loosely coupled messaging patterns, developers look to implement the same pattern, opting for something like duplex GetCustomersRequest and GetCustomersResponse. The reasoning is simple and straightforward – it is difficult to push data over the web to consumers.

However, there are still ways to disconnect the preparation of the data from its usage thus gaining many of the advantages of pub/sub.

By employing REST principles and modelling our customer list as an explicit resource, web-based consumers would simply perform regular HTTP GET operations on the URI to get the list of customers.

The resource itself could be a simple XML file – it wouldn’t need to be dynamic at all.

You can get all the scalability benefits of pub/sub for web based consumers. All you need is a bit of REST

Also, “passing reference data in a message makes the message-consuming systems dependent on the knowledge and availability of actual persistent data that is stored “somewhere”. This data must separately be accessed for the sake of understanding the event that is represented by the message.”

The discussion of self-contained events can be compared to integration databases vs application databases.

Centralized Integration – Pros & Cons

If everything in a system can access a central datastore, it is enough for one party to publish an event containing only the ID of an entity that that party previously entered/updated. Upon receiving that event, a subscriber would go to the central datastore and get the fields its interested in for that ID. The advantage of this approach is that the minimal amount of data necessary crosses the network, as subscribers only retrieve the fields that interest them. Martin Fowler describes the disadvantages as:

“An integration database needs a schema that takes all its client applications into account. The resulting schema is either more general, more complex or both. The database usually is controlled by a separate group to the applications and database changes are more complex because they have to be negotiated between the database group and the various applications.”

This is far from being aligned with the principle of autonomy so important to SOA. In that respect, the architectural principle of self-contained messages points us away from those problems and towards more autonomous services.

However, once we have these autonomous business services in place, we may find that we don’t need 100% fully self-contained messages anymore.

A Real-World Example

Let’s say we have 3 business services, Sales, Fulfillment, and Billing.

Sales publishes an OrderAccepted event when it accepts an order. That event contains all the order information.

Both Fulfillment and Billing are subscribed to this event, and thus receive it.

Fulfillment does not ship products to the customer until the customer has been billed, so it just stores the order information internally, and is done.

Billing starts the process of billing the customer for their order, possibly joining several orders into a single bill. After completing this process, it publishes a CustomerBilled event containing all billing information, as well as the IDs of the orders in that bill. It does not put all the order information in that event, as it is not the authoritative owner of that data.

When Fulfillment receives the CustomerBilled event, it uses the IDs of the orders contained in the event to find the order information it previously stored internally. It does not need to call the Sales service for this information or contact some central Master Data Management system. It uses the data it has, and goes about fulfilling the orders and shipping the products to the customer, finally publishing its own OrderShipped event.

Notice, as well, that in the original OrderAccepted event there were the IDs of products the customer ordered. These product IDs originated from another service, Merchandising, responsible for the product catalog. The same thing can be said for the customer ID originating from another service – Customer Care.

The Issue of Time

One could argue that since subscribers use previously cached data when processing new events, that data might not be up to date. Also, we may have race conditions between our services. In the above example, if Billing was extremely fast and more highly available than Fulfillment. Billing could have received the OrderAccepted event, processed it, and published the CustomerBilled event before Fulfillment had received the OrderAccepted event. In short, the CustomerBilled and OrderAccepted messages could be out of order in Fulfillment’s queue.

What would Fulfillment do when trying to process the CustomerBilled message when it doesn’t have the order information?

Well, it knows that the world is parallel and non-sequential, so it does NOT return/log an error, but rather puts that message in the back of the queue to be processed again later (or maybe in some other temporary holding area). This enables the OrderAccepted message to be processed before the CustomerBilled message is retried. When the retry occurs, well, everything’s OK – it’s worked itself out over time.

In the case where we retry again and again and things don’t work themselves out (maybe the OrderAccepted event was lost), we move that message off to a different queue for something else to resolve the conflict (maybe a person, maybe software). If/when the conflict is resolved (got the Sales system / messaging system to replay the OrderAccepted event), the conflict resolver returns the CustomerBilled message to the queue, and now everything works just fine.

As all of this is occurring, the only thing that’s visible to external parties is that it happens to be taking longer than usual for the OrderShipped event to be published. In other words, time is the only difference.

Summary

The problem of non-self-contained events is mitigated first and foremost by business services in SOA, and the apparent issue of time-synchronization by business logic inside these services.

Don’t be afraid to put IDs in your messages and events.

Do be afraid of using those IDs to access datastores shared by multiple “services”.

Using IDs to correlated current events to data from previous events is not only OK, it’s to be expected.

The architectural principle of fully self-contained messages steers us away from the problems of Integration Databases and towards Application Databases, autonomous services, and a better SOA implementation. From there, following the principle of autonomy from a business perspective, will lead us to services not publishing data in their messages that is owned by other services, taking us the next step of our journey to SOA.

Related Content

[Podcast] Message Ordering – Is it cost effective?

Don’t EDA between existing systems

[Podcast] Handling dependencies between subscribers in SOA

Durable Messaging

In order to prevent a message from being lost when it is sent from a publisher to a subscriber, the message is written to disk on the publisher side, and then forwarded to the subscriber, where it is also written to disk. This store-and-forward mechanism enables our systems to gracefully recover from either side being temporarily unavailable.

In my MSDN article on this topic, I outlined some problems with this approach. These problems are exacerbated for publishers. Imagine a publisher with 40 subscribers, publishing 10 messages a second, each containing 1MB of XML. If 10 of the subscribers are unavailable, that’s 100MB of data being written to the publisher’s disk every second, 6GB every minute. That’s liable to bring down a publisher before an administrator brews a cup of coffee.

Publishers have no choice but to throw away messages after a certain period of time.

Publisher Contracts

The whole issue of contracts and schema is considered one of the better understand parts of SOA. Unfortunately, the operational aspects of service contracts is hardly ever taken into account.

On top of the schema of the messages a service publishers, additional information is needed in the contract:

1. How big will this message be?
2. How often will it be published?
3. How long will this message be stored if a subscriber is unavailable?

This first two pieces of information are important for subscribers to do load and capacity planning. The last one is the most important as it dictates the required availability and fault-tolerance characteristic of subscribers.

For Example

In the canonical retail scenario, when our sales service accepts an order, it publishes an order accepted event. Other services subscribed to this event include shipping, billing, and business intelligence.

While shipping and billing are highly available and able to keep up with the rate at which orders are accepted, the business intelligence service is not. BI has two main parts to it – a nightly batch that does the number crunching, and a UI for reporting off of the results of that number crunching. Some even do the reporting in a semi-offline fashion, emailing reports back to the user when they’re ready.

Furthermore, nobody’s going to invest in servers for making BI highly available.

And wasn’t the whole point of this publish/subscribe messaging to keep our services autonomous? That not all services have to have the same level uptime?

Houston, do we have a problem.?

Data Freshness

There is a glimmer of light in all this doom and gloom.

Not all services have the same data freshness requirements.

The business intelligence service above doesn’t need to know about orders the second they’re accepted. A daily roll-up would be fine, and an hourly roll-up bring us that much closer to “real time business intelligence”.

So, while BI is ready to accept the sales message schema, it would like a slightly different contract around it – less messages per unit of time, more data in each message.

From the operational perspective of the sales service, it would be cost effective to have less “online” subscribers. It could even take things a few steps further. Instead of using the regular messaging backbone for transmitting these hourly messages, it could use FTP. The data could even be zipped to take up even less space. Since the total data size is less than the corresponding online stream, is stored on cheaper, large storage, and the number of subscribers for this zipped, hourly update is fairly small, these messages can be kept around far longer.

If you’ve heard about consumer-driven contracts, this is it.

Note that we’re still talking about the same logical message schema.

Summary

It’s not that lost notifications aren’t a problem.

It’s that they feed the design process in such a way that the resulting service ecosystem is set up in such a way that notifications won’t get lost. I know that that sounds kind of recursive, but that’s how it works. Either subscribers take care of their SLA allowing them to process the online stream of events, or they should subscribe to a different pipe (which will have different SLA requirements, but maybe they can deal with those).

It make sense to have multiple pipes for the same logical schema.

It’s practically a necessity to make pub/sub a feasible solution.

Related Content

MSDN article on messaging and lost messages

Durable messaging dilemmas

Additional logic required for service autonomy

More in depth example on events and pub/sub between services

Consumer-Driven Contracts

Dennis asked this:

There are different design choices in a SOA, even when you already have identified the services. I have a simple example that I would like to share:

Imagine a order-to-cash process. One part of that process is to register an order. Suppose we have two services, Order Service and Inventory Service. The task is to register the order and make a corresponding reservation of the stock level. I would be pleased to have the groups view on the following 3 design options (A, B, C):

A.
1. The “process/application” sends a message (sync or async) to “registerOrder” on the Order Service.
2. The “process/application” sends another message (sync or async) to “reserveStock” on the the Inventory Service.

B.
1. The “process/application” sends a message (sync or async) to “registerOrder” on the Order Service.
2. The Order Service sends a message (sync or async) to “reserveStock” on the the Inventory Service.

C.
1. The “process/application” sends a message (sync or async) to “registerOrder” on the Order Service.
2. The Order Service publishes an “orderReceived” event.
3. The Inventory Service subscribes to the “orderReceived” event .

On the whole “already identified the services” thing – naming a service doesn’t mean much. It’s all about allocating responsibility, and until that’s been done, those “services” don’t give us very much information.

Business Services

If we were to view this example in light of business services, and look at the business events that make up this process, maybe we’d get a different perspective.

Three business services: Sales, Inventory, and Shipping.

In Sales, many applications and people may operate, including the person and the application he used to submit the order. When the order is submitted and goes through all the internal validation stuff, Sales raises an OrderTentativelyAccepted event.

Inventory and Orders

Inventory, which is subscribed to this event, checks if it has everything in stock for the order. For every item in the order on stock, it allocates that stock to the order and publishes the InventoryAllocatedToOrder event for it. For items/quantities not in stock, it starts a long running process which watches for inventory changes.

When an InventoryChanged event occurs, it matches that against orders requiring allocation – if it finds one that requires stock, based on some logic to choose which order gets precedence, it publishes the InventoryAllocatedToOrder event.

Sales, which is subscribed to the InventoryAllocatedToOrder event, upon receiving all events pertaining to the order tentatively accepted, will publish an OrderAccepted event.

Orders and Shipping

When Inventory receives the OrderAccepted event, it generates the pick list to bring all the stock from the warehouses to the loading docks, finally publishing the PickListGenerated event containing target docks.

When Shipping receives the PickListGenerated event, it starts the yard management necessary to bring the needed kinds of trucks to the docks.

What else is possible

I could go on, talking about things like the maximum amount of time stock of various kinds can wait to be loaded on trucks, subscribing to earlier events to employ all kinds of optimization and prediction algorithms, having a Customer Care service notifying the customer about what’s going on with their order (probably different for different kinds of customers and preferred communication definitions). Obviously, we’d need a Billing service to handle the various kinds of billing procedures, whether or not the customer has credit, pays upon delivery, etc.

It turns out that many business domains map very well to this join of SOA and EDA.

What an ESB is for

When we have these kinds of business services primarily publishing events and subscribing to those of other services, you don’t need much else from your “enterprise service bus”. All sorts of transformation, routing, and orchestration capabilities don’t come into play at all.

In all truthfullness, those bits of functionality are really just a historical artifact of their broker heritage.

Don’t get me wrong, sometimes a broker is a nice thing to have – behind a service boundary in order to perform some complex integration between existing legacy applications.

Just keep that stuff in its place – not between services.

Complex Event Processing

We can look at how Sales transitions an order from being tentatively accepted to being accepted as requiring event correlation around InventoryAllocatedToOrder events. This isn’t exactly “complex” in its own right. If there were some kind of CEP engine that did this for us out of the box, it might be a possible technology choice for implementing this logic within our service.

As we add more concerns, like time, we may find new ways to make use of this engine. For instance, if the time to provide the order to the customer is approaching, we may choose to split the order into two – accepting one for which we have all the stock allocated, and leaving the second as tentatively accepted.

Summary

While it is difficult to move forward on service responsibility without discussing the events it raises and those it subscribe to, the whole issue of CEP can be postponed for a while.

Although there aren’t many who would say that EDA is necessary for driving down coupling in SOA, or that SOA won’t likely provide much value without EDA, or that SOA is necessary for providing the right boundaries for EDA, it’s been my experience that that is exactly the case.

CEP, while being a challenging engineering field, and managing the technical risks around it necessary for a project to succeed in some circumstances, and really shines when used under the SOA/EDA umbrella, it should not be taken by itself and used at the topmost architectural levels.

Related Content

SOA and Enterprise Processes

How client interaction fits with SOA

Time and SOA

Durable Messaging for Fault-Tolerant Services

And if you’re wondering about how to handle all that complexity inside services (different kinds of billing, periodic tests for electronics inventory, etc), you might like listening to this podcast about business components.

Watch that first step

Although sometimes described as the first step of an organization moving to SOA, web-service-izing everything results in synchronous, blocking, request/response interaction between services. The problem being that if one service were to become unavailable, all consumers of that service would not be able to perform any work. With the deep service “call stacks” this architectural style condones, the availability and performance of the entire organization will be dictated by the weakest link.

So, while I’d agree that many organizations do need to take this step, I’d caution against going into production at this step.

Pub/Sub Considered Helpful

When services interact with each other using publish/subscribe semantics we don’t have that technical problem of blocking. Subscribers cache the data published to them (either in memory or durably depending on their fault-tolerance requirements) thus enabling them to function and process requests even if the publisher is unavailable.

Consider the following scenario:

Let’s say we have an e-commerce site, a part of our Sales service responsible for selling products. Another service, let’s call it merchandising, is responsible for the catalog of products, and how much each product costs. Sales is subscribed to price update events published by Merchandising and saves (caches) those prices in its own database. When a customer orders some products on the site, Sales does not need to call Merchandising to get the price of the product and just uses the previously saved (cached) price. Thus, even if Merchandising is unavailable, Sales is able to accept orders. This is a big win as our merchandising application is not nearly as robust as our sales systems.

Yet, there are scenarios where data freshness requirements prevent this.

Too Much of a Good Thing?

Technically, the above story is accurate. There is nothing technically preventing Sales from accepting orders. Yet consider a scenario where Merchandising is down or unavailable for an extended period of time. While this may not be entirely likely for two servers in the same data center, consider physical kiosks which customers can use to buy products. Those kiosks may not receive updates for days. Should they accept orders?

That’s really a question to the business. If pricing data is stale for a time period greater than X, do not sell that item. The value of X may even be different for different kinds of products. Keep in mind that this issue only arose since we architected our services to be fully autonomous. In a synchronous systems architecture, this issue would not come up. As such, it is our responsibility as architects to go digging for these requirements as well as explaining to the business what the tradeoffs are.

In order to have more up to date data, we need to invest in more available hardware, networks, and infrastructure. This needs to be balanced against the predicted increase in revenue that more up to date (read higher) prices would give us.

You Can Get What You Pay For

Beyond the additional cost of writing that additional logic, and the perceived increased complexity, another difference to note between this architectural style and the synchronous/traditional one is that it puts control of spending back in the hands of business.

In a synchronous architecture, in order to achieve required performance and availability, all systems need to be performant requiring across the board investments in servers, networks, and storage. Without investing everywhere, the weakest link is liable to undo all other investments. In other words, your developers have made your investment choices for you. Scary, isn’t it.

A more prudent investment strategy would prefer spending on services that give the biggest bang for the buck, better known as return on investment. A pub/sub based architecture allows investing in data-freshness where it makes the most sense. For example, in sales of high profit products to strategic customers rather than inventory management of raw materials for products slated to be decommissioned.

That sounds a lot like IT-Business Alignment.

Maybe there’s something to this SOA thing after all…

Read more about:

7 Questions for Service Selection

7 Questions around data freshness 

Event-Driven Architecture and Legacy Applications

Autonomous Services and Enterprise Entity Aggregation

Or listen to a podcast describing Business Components, the connection of pub/sub and SOA.

This innocuous question comes up a lot. Usually I get this question after a short problem domain description. One of these came up on the nServiceBus discussion groups. Ayende took it and ran with it turning it into a nice blog post, An exercise in designing SOA systems. I’ve been meaning to write something myself. Bill put up a response already in his Service Granularity Example. So, I’m late to the party, again, but here we go.

It’s almost impossible to know, right away, which services are appropriate.

So, I’m going to focus more on the process of getting there, rather than describing the solution itself.

The domain deals with a placement agency placing physicians in positions at hospitals.

1. So, what does it actually do?

In Ayende’s post, he describes several services, but I’d rather look at them as use cases: registering an open position, registering a candidate, verifying their credentials, etc. It’s worth going through this requirements process. It doesn’t necessarily translate immediately to services, but there’s value in it.

2. What does it do it to?

We should also be looking at the data model, an entity relationship diagram (ERD) , where we see that we may have placed a certain physician at a number of positions. It’s also important for us to know about under which circumstances a physician finished their employment at a previous position before, say, trying to place them at a position in the same hospital or chain of hospitals. Don’t go thinking that this what the database schema will look like, it’s all about understanding connections between various bits of data.

3. When does that happen?

The next step is to map the uses cases above to the entities in the ERD, which entity is used in which use case. It’s also important to differentiate between entities (or even more importantly, specific fields of entities) that are used in a read-only fashion within a given use case. For instance, when registering a new position, we’ll want to check that against other open positions in the same hospital so we don’t end up registering the same position twice. Also, we might want to suggest verified physicians whose credentials match the position’s requirements. Data we wouldn’t be interested in might be which other physicians we placed at that hospital.

4. What just happened?

Another valuable perspective on the problem domain is the business process view – what are the interesting business events in the system and how they unfold over time. For instance, physician registered, position opened, physician’s credentials verified, and physician placed in position (or position filled by physician) are events that describe a different business perspective than use cases.

5. How do I decide?

Once we know what events there are, we can start looking at what kind of decisions we might want to make when those events occur and what data we’d need to make those decisions. These decisions may be as simple as updating a database or sending an email to a user. They also may include more advanced logic like when the profitability of an agreement with a specific hospital chain changes, prefer placing physicians in positions in that chain over others.

6. How do I deal with all this information?

After we have all of this information, we can start looking for cohesive bunching across all of these axes using these rules:

• Data that is modified by a use case gets published as an event.
• Data that is required by a use case for read-only purposes, arrives as the result of subscribing to some event.

Look for rules that differentiate behaviour based on the properties of data. Look for a correlation to some business concept. For instance, physicians probably won’t be changing their specialization, and open positions often deal with a certain specialization. Therefore, specific data instances tied to two different specializations can be said to be loosely coupled.

7. Which property slices across the domain?

Even though the ERD may not have made it clear, and the use cases didn’t show any particular break-down, nor did the events call out this point, the key to finding the way a business domain decomposes into services lies in decoupling specific data instances.

Actually, at this point we can clump autonomous components (mere technical bits) that handle a single message, into more granular business components.

If you think about it, it makes a lot of sense. The kind of credential checking you’d do for physicians specializing in brain surgery would likely be different than for general practitioners. The kind of information you’d store would, therefore, also be different.

But, which services do I need?

Quite frankly, I don’t have enough information to know.

But if we had continued this conversation, going through issues like transactional consistency, availability requirements, and other non-functional issues we could have  gotten there.

If there’s one thing that I hope you got out of this, it’s that the questions are what’s important. The iterative process of looking at the problem domain from various perspectives, incorporating the new-found knowledge, and asking more questions is what leads us to a solution. But we don’t stop there. We keep looking for characteristics which split services apart into business components, and for consistency requirements that brings autonomous components together into services.

It’s not easy, but by focusing on these simple questions, you can get to a coherent service oriented architecture.

One of the questions that Martin started answering was how teams can start getting into the messaging state-of-mind. Unfortunately, the conversation veered off into what kind of messaging interactions are appropriate leaving the original question unanswered.

I’m hoping to address this topic with some of the information I’m putting up on the nServiceBus site. There’s always Gregor and Bobby’s excellent EIP book that I think is a must for anybody writing distributed systems.

Enjoy.

Jim brought the concept of cohesion to the regular SOA discussions around loose coupling in his post Anemic Service Model, which I think, all in all, is a very good idea.

Naïve Service Composition

Jim first calls out a common anti-pattern that seems to have become quite rampant – I’d call it naïve service composition if only the things being composed could even be called services. And I think the tone being set is correct – a service needs to meet a stronger set of criteria than just being able to be composed. Multiple services sharing the same logical data store (in that the same actual rows/data elements are managed by multiple services) probably means there’s an encapsulation problem here. I agree with Jim sentiment here:

“On the one hand we’re inclined, and indeed encouraged by the SOA brigade, to think of this architecture as a good fit for purpose because it is very loosely coupled. Since every component or service is decoupled from every other component or service it should be possible to arrange and re-arrange them in a Lego-style in a myriad of useful ways. Building out “business services” from some more fundamental set of services is how the books tell us to do it. In fact we could even do that quite easily with point-and-[click] BPM tools, ruling out such overheads as developers and change management along the way. Right?”

MVC? There are, like, 6 of them!

However, I disagree with some of the conclusions that Jim draws from that point. Jim states “build your services to implement business processes”, and that services are “just an instance of MVC”. I’m going to leave alone the MVC statement since there are like 6 documented kinds of MVC not including the Front Controller stuff that the web guys are now calling MVC. I’m going to focus on the business process advice. JJ also doesn’t seem to agree with this advice. As Savas has already taken issue with the tone of JJ’s response, I’ll keep my focus on the content.

Visual Cobol

First of all, in my previous conversations with Jim he had already denounced the procedural nature of composing higher-level business processes out of smaller services which implement small bits of common activities. Visual Cobol was how he described it. In JJ’s follow-up post, he called out the necessary aspect of autonomy that jives with Jim’s cohesion principle.

I’m a bit concerned about the way JJ tends to version what SOA means over time. It might make it impossible to have intelligent design discussions without tagging each sentence with “as SOA meant in 2006″. I acknowledge that the accepted meaning of SOA by various vendors has changed over the years. However, I’ve found that meanings rooted in decades of computer science tend to last and provide value that outlasts much of the industry-buzzword-bingo (SOA 2.0 anyone?).

Cohesion, Business Domains, and Business Processes

My view of the original cohesion principles Steve discusses in his 2005 article Old Measures for New Services takes a business spin to Functional Cohesion:

A service should be responsible for one business domain.

If we jump off from this point, we’ll see that certain business processes which occur entirely in one business domain are fully encapsulated, whereas those macro-processes which cross many domains (like Order to Cash) cross multiple services – they do not become a service since that would break the “one business domain” rule. Given that services are loosely coupled, avoiding temporal coupling leads to services raising events. Thus, macro-processes are really just a series of events of various services where each service does its own internal business processes.

Enterprise Processes >> Business Processes

I think that maybe some of the difficulty in discussing concrete SOA guidance has to do with granularity. I’ve started calling those macro-processes something different from business processes, and that may just bring me full circle to Jim’s guidance.

An Enterprise Process is any process which involves multiple business domains.

Under that definition, a service may be responsible for multiple business processes in the same business domain. But still, one business process is usually not a service by itself.

Business Components & Autonomous Components to the Rescue

Finally, by introducing the additional levels of decomposition of business components and autonomous components I’ve found that we can focus the discourse on one concern at a time. My presentation on the topic can be found here. The 30 second pitch is this:

Business domains are inherently partitionable – data and rules. A business component represents one partition. An example of this is the domain of Sales being partitioned by strategic and non-strategic customers. Although the data structure might be similar or the same, the actual rows/data elements are not shared. Rules around discounts are different.

Within a business component, different activities should not interfere with each other. An autonomous component represents one activity. In our example, reporting on orders from strategic customers should not interfere with accepting their orders. As such, those activities should have different messages coming in on different endpoints. Each endpoint could have different characteristics, like durability. Losing a request for a report when a server restarts isn’t a big deal, however not a good idea for orders.

For more information you could check out these episodes from my podcast:

Business and Autonomous Components in SOA

Using Autonomous Components for SLAs in SOA

Questions and comments are always welcome.

Typically, in such an environment [SOA], services tend to be parts of multiple systems. For example, consider a Products service! It might start its life as part of a sales system. Later it might be involved in a purchasing system, a product development system, a marketing system, a warehousing system, and perhaps in several other systems too. This process may take years, and it really never ends. The service is the same, but its responsibilities and its external exposure are increased with each system it’s enrolled in.

One of the core tenets of SOA that all vendors and analysts agree upon is that there should be loose coupling between services. If you were to design such a product service, it’s clear that changing part of its interface could break almost every system in the enterprise. That doesn’t sound like loose coupling to me.

If there’s one place that is the source of loose coupling – it’s the business. Warehousing is viewed by the business as being fairly independent of Marketing. While Sales might make use of data created in Product Development, business wouldn’t want any problems in IT related to Product Development to inhibit Sales ability to accept orders. That is another kind of loose coupling – the ability of one service to make use of “not-accurate-up-to-the-millisecond” data created by another service. That’s known as loose “temporal” coupling, as in loose coupling in the dimension of time.

Loosely-Coupled Services

So, in the example described we’d see the following services:

• Sales
• Purchasing
• Product Development
• Marketing
• Warehousing / Inventory

Product data would flow between the services but each would have a very different internal view of it.

• Product Development would be more interested in managing the schedule and risk around a product’s development.
• Marketing would probably be more focused on its relation to competing products and pricing.
• Purchasing would be maintaining data as to which suppliers are being used to supply raw materials for the production of the product.
• Sales would be looking at actually accepting orders and giving discounts.
• Warehousing would be focused on the storage and transportation aspects of the product.

As you can see, there is very little overlap in the data between these services even on something similar like product data. The logic of each service around the management of its data would be even more different. This leads to services with a high level of autonomy.

There Be Dragons…

Without starting at this business-level loose coupling, I doubt that any technical effort will succeed. That is to say every time I’ve seen this style implemented it has failed, but that’s no proof. Conversely, every time that we did start our SOA efforts by identifying the clear business fracture lines, we were able to maintain loose coupling all the way down. That is not to say that it always will succeed, but the logic is sound.

I suppose that the difference between my view on SOA and Sundblad’s stems from the fact that they put systems at a higher level of abstraction than services, and I put services on top. Regardless, I do agree with their views about architecture and engineering and consider them quite valuable.

I was wondering if any of my loyal subscribers would be interested in getting a set of DVDs containing Udi talking for hours and hours about how to identify services, map out cross-service business processes, zero in on business fracture points to further decompose services into business components, and decompose those into autonomous components by analyzing non-functional message properties,  summing up with using all that information for choosing cost-effective technologies for each autonomous component.

In other words, get 5 days of training you can pause, think about, and replay as many times as you need. There’s something for almost every phase of an enterprise project, from top level architecture, through coding, testing, to deployment tips and monitoring tactics, so you can pick up what you need – right when you need it.

Please bear with me as I get the processes in place for getting this out.

I’m wondering – how valuable do you think it would be to have weekly live online Q&A sessions as opposed to the more asynchronous (and scalable) simple forum thing?

Just so I can see what I need to be preparing myself for, please leave a comment below expressing your interest. If you also know someone else who might benefit from this, drop them a link. The last thing I want to have happen is for this to take months and months to get out because I didn’t prepare things in advance that I could have.

And a big thanks to Simon and the gang in Australia for helping make this happen. It was a great two weeks and I thank you for that.

Here’s the core list from Joe Armstrong’s book, Programming Erlang:

“In Erlang:

• Creating and destroying processes is very fast.
• Sending messages between processes is very fast.
• Processess behave the same way on all operating systems.
• We can have very large numbers of processes.
• Processes share no memory and are completely independent.
• The only way for processes to interact is through message passing.”

In nServiceBus, we don’t create or destroy processes – that’s a Windows issue. Instead, we just do messaging with endpoints. If there’s a process behind that endpoint, and it responds, then other interesting things can occur.

In the continued list:

• Message passing is asynchronous.
• Processes can monitor each other.
• It is possible to selectively receive messages.
• Remote processes appear largely the same as local processes.

All of this is part of the design philosophy of nServiceBus. While I have yet to see a carrier-grade implementation of nServiceBus, we are enjoying very impressive system-wide uptimes in production. Oh, and the programming model is still plain-old .NET, so you don’t have to learn any new languages or environments (even though I think that you might learn something – I know I did).

Not so.

The other day I sat down to implement and test a non-trivial business process, and the testing was far from easy. Now as developers go, I’m not great, or an expert on unit testing or TDD, but I’m above average. It should not have been this hard. And I tried doing it with Rhino.Mocks, TypeMock, and finally Moq. It seemed like I was in a no-mans-land, between trying to do state-based testing, and setting expectations on the messages being sent (as well as correct values in those messages), nothing flowed.

Until I finally stopped trying to figure out how to test, and focused on what needed to be tested. I mean, it’s not like I was trying to build a generic mocking framework like Daniel.

Here’s an example business process, or actually, part of one, and then we’ll see how that can be tested. By the way, there will be a post coming soon which describes how we go about analysing a system, coming up with these message types, and how these sagas come into being, so stay tuned. Either that, or just come to my tutorial at QCon.

On with the process:

1. When we receive a CreateOrderMessage, whose “Completed” flag is true, we’ll send 2 AuthorizationRequestMessages to internal systems (for managers to authorize the order), one OrderStatusUpdatedMessage to the caller with a status “Received”, and a TimeoutMessage to the TimeoutManager requesting to be notified – so that the process doesn’t get stuck if one or both messages don’t get a response.

2. When we receive the first AuthorizationResponseMessage, we notify the initiator of the Order by sending them a OrderStatusUpdatedMessage with a status “Authorized1”.

3. When we get “timed out” from the TimeoutManager, we check if at least one AuthorizationResponseMessage has arrived, and if so, publish an OrderAcceptedMessage, and notify the initator (again via the OrderStatusUpdatedMessage) this time with a status of “Accepted”.

And here’s the test:

    public class OrderSagaTests
    {
        private OrderSaga orderSaga = null;
        private string timeoutAddress;
        private Saga Saga;     

        [SetUp]
        public void Setup()
        {
            timeoutAddress = "timeout";
            Saga = Saga.Test(out orderSaga, timeoutAddress);
        }     

        [Test]
        public void OrderProcessingShouldCompleteAfterOneAuthorizationAndOneTimeout()
        {
            Guid externalOrderId = Guid.NewGuid();
            Guid customerId = Guid.NewGuid();
            string clientAddress = "client";     

            CreateOrderMessage createOrderMsg = new CreateOrderMessage();
            createOrderMsg.OrderId = externalOrderId;
            createOrderMsg.CustomerId = customerId;
            createOrderMsg.Products = new List<Guid>(new Guid[] { Guid.NewGuid() });
            createOrderMsg.Amounts = new List<float>(new float[] { 10.0F });
            createOrderMsg.Completed = true;     

            TimeoutMessage timeoutMessage = null;     

            Saga.WhenReceivesMessageFrom(clientAddress)
                .ExpectSend<AuthorizeOrderRequestMessage>(
                    delegate(AuthorizeOrderRequestMessage m)
                    {
                        return m.SagaId == orderSaga.Id;
                    })
                .ExpectSend<AuthorizeOrderRequestMessage>(
                    delegate(AuthorizeOrderRequestMessage m)
                    {
                        return m.SagaId == orderSaga.Id;
                    })
                .ExpectSendToDestination<OrderStatusUpdatedMessage>(
                    delegate(string destination, OrderStatusUpdatedMessage m)
                    {
                        return m.OrderId == externalOrderId && destination == clientAddress;
                    })
                .ExpectSendToDestination<TimeoutMessage>(
                    delegate(string destination, TimeoutMessage m)
                    {
                        timeoutMessage = m;
                        return m.SagaId == orderSaga.Id && destination == timeoutAddress;
                    })
                .When(delegate { orderSaga.Handle(createOrderMsg); });     

            Assert.IsFalse(orderSaga.Completed);     

            AuthorizeOrderResponseMessage response = new AuthorizeOrderResponseMessage();
            response.ManagerId = Guid.NewGuid();
            response.Authorized = true;
            response.SagaId = orderSaga.Id;     

            Saga.ExpectSendToDestination<OrderStatusUpdatedMessage>(
                    delegate(string destination, OrderStatusUpdatedMessage m)
                    {
                        return (destination == clientAddress &&
                                m.OrderId == externalOrderId &&
                                m.Status == OrderStatus.Authorized1);
                    })
                .When(delegate { orderSaga.Handle(response); });     

            Assert.IsFalse(orderSaga.Completed);     

            Saga.ExpectSendToDestination<OrderStatusUpdatedMessage>(
                    delegate(string destination, OrderStatusUpdatedMessage m)
                    {
                        return (destination == clientAddress &&
                                m.OrderId == externalOrderId &&
                                m.Status == OrderStatus.Accepted);
                    })
                .ExpectPublish<OrderAcceptedMessage>(
                    delegate(OrderAcceptedMessage m)
                    {
                        return (m.CustomerId == customerId);
                    })
                .When(delegate { orderSaga.Timeout(timeoutMessage.State); });     

            Assert.IsTrue(orderSaga.Completed);
        }
    }

You might notice that this style is a bit similar to the fluent testing found in Rhino Mocks. That’s not coincidence. It actually makes use of Rhino Mocks internally. The thing that I discovered was that in order to test these sagas, you don’t need to actually see a mocking framework. All you should have to do is express how messages get sent, and under what criteria those messages are valid.

If you’re wondering what the OrderSaga looks like, you can find the code right here. It’s not a complete business process implementation, but its enough to understand how one would look like:

using System;
using System.Collections.Generic;
using ExternalOrderMessages;
using NServiceBus.Saga;
using NServiceBus;
using InternalOrderMessages;     

namespace ProcessingLogic
{
    [Serializable]
    public class OrderSaga : ISaga<CreateOrderMessage>,
        ISaga<AuthorizeOrderResponseMessage>,
        ISaga<CancelOrderMessage>
    {
        #region config info     

        [NonSerialized]
        private IBus bus;
        public IBus Bus
        {
            set { this.bus = value; }
        }     

        [NonSerialized]
        private Reminder reminder;
        public Reminder Reminder
        {
            set { this.reminder = value; }
        }     

        #endregion     

        private Guid id;
        private bool completed;
        public string clientAddress;
        public Guid externalOrderId;
        public int numberOfPendingAuthorizations = 2;
        public List<CreateOrderMessage> orderItems = new List<CreateOrderMessage>();     

        public void Handle(CreateOrderMessage message)
        {
            this.clientAddress = this.bus.SourceOfMessageBeingHandled;
            this.externalOrderId = message.OrderId;     

            this.orderItems.Add(message);     

            if (message.Completed)
            {
                for (int i = 0; i < this.numberOfPendingAuthorizations; i++)
                {
                    AuthorizeOrderRequestMessage req = new AuthorizeOrderRequestMessage();
                    req.SagaId = this.id;
                    req.OrderData = orderItems;     

                    this.bus.Send(req);
                }
            }     

            this.SendUpdate(OrderStatus.Recieved);     

            this.reminder.ExpireIn(message.ProvideBy - DateTime.Now, this, null);
        }     

        public void Timeout(object state)
        {
            if (this.numberOfPendingAuthorizations <= 1)
                this.Complete();
        }     

        public Guid Id
        {
            get { return id; }
            set { id = value; }
        }     

        public bool Completed
        {
            get { return completed; }
        }     

        public void Handle(AuthorizeOrderResponseMessage message)
        {
            if (message.Authorized)
            {
                this.numberOfPendingAuthorizations--;     

                if (this.numberOfPendingAuthorizations == 1)
                    this.SendUpdate(OrderStatus.Authorized1);
                else
                {
                    this.SendUpdate(OrderStatus.Authorized2);
                    this.Complete();
                }
            }
            else
            {
                this.SendUpdate(OrderStatus.Rejected);
                this.Complete();
            }
        }     

        public void Handle(CancelOrderMessage message)
        {     

        }     

        private void SendUpdate(OrderStatus status)
        {
            OrderStatusUpdatedMessage update = new OrderStatusUpdatedMessage();
            update.OrderId = this.externalOrderId;
            update.Status = status;     

            this.bus.Send(this.clientAddress, update);
        }     

        private void Complete()
        {
            this.completed = true;     

            this.SendUpdate(OrderStatus.Accepted);     

            OrderAcceptedMessage accepted = new OrderAcceptedMessage();
            accepted.Products = new List<Guid>(this.orderItems.Count);
            accepted.Amounts = new List<float>(this.orderItems.Count);     

            this.orderItems.ForEach(delegate(CreateOrderMessage m)
                                        {
                                            accepted.Products.AddRange(m.Products);
                                            accepted.Amounts.AddRange(m.Amounts);
                                            accepted.CustomerId = m.CustomerId;
                                        });     

            this.bus.Publish(accepted);
        }
    }
}

All this code is online in the subversion repository under /Samples/Saga.

Questions, comments, and general thoughts are always appreciated.

After the grand release of WPF, and the industry’s collective shrug and back to business, Microsoft stirs the pot again.

I’ve read Brian’s authoritative description, even done some of the examples he’s outlined, and let me tell you, tech won’t help.

Again.

I don’t know about differentiation, but empowerment is important. Make the system work for the user. What an idea.

Let the user specify minimal inventory levels for products, and rules for replenishing. Give them a dashboard where they can see the status – what’s back ordered, orders expected to be authorized in the next relevant time interval, recent supplier timeliness, etc. If you’re thinking that this ties in to Event Driven Architecture, you’re right. Let the user subscribe to business events that interest them, pop up a messenger-like notification when they occur. Let the user click on the data in there, and have the rest of the UI synchronize around that.

Purchasing has struck a new deal with a supplier? Let me know. Click. Products they supply open in one view. Suppliers providing the same or similar products open in another. Contact info in another. Replenishment times in another.

Everything synchronized. Everything in real time.

Let them seamlessly work connected and disconnected.

You do that with regular boring winforms, and they’ll kiss the ground you walk on.

Differentiated user experience? Shrug.

Our long time listener Bill asks:

Hi Udi,

I have a question around processing of messages in proper order. When leveraging multiple threads to process messages in a message queue, it is possible for the second message in the queue to get processed before the first – especially if the first message is considerably larger than the second. I have taken a lot of care to make sure that messages are sent in the correct order, only to find that the receiving system can process them out of order anyway.

Consider a Policy Created notification, which must come before a Policy Approved notification. If both messages are sitting in the queue when the receiving service starts up, the approval message can be processed before the creation message. How can I make sure that message ordering is respected by the receiving system? I am using WCF/MSMQ as the underlying transport by the way. The only way I have found so far is to limit the receiving service to a single thread, which is by no means desirable.

Best Regards,

Bill

Download

Download via the Dr. Dobb’s site

Or download directly here.

Additional References

• Blog post: In-Order Messaging a Myth?
• Blog post: Handling Messages out of Order

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

The important thing to note is that if we just automatically return the message to the queue, we may get “stuck” with that message if the first PolicyCreatedMessage never arrived. This opens us up to a Denial-of-Service attack by quite simply flooding us with a bunch of messages that never get cleaned up.

Anyway, the general idea is to first try the regular happy path, and only if we see that prerequisite data isn’t available, do we see if another thread may be working on that data. This is done by decreasing the isolation level of our transaction from the regular ReadCommitted to ReadUncommitted. This will enable our thread to see if some other thread inserted the policy in to the Policies table but hasn’t committed its transaction yet.

The next step will be how we take this code and make it generic, so that we don’t have write the same code over and over again for the different kinds of message handlers we have.

But that will have to wait until the next installment

I have a question around processing of messages in proper order.  When leveraging multiple threads to process messages in a message queue, it is possible for the second message in the queue to get processed before the first – especially if the first message is considerably larger than the second.  I have taken a lot of care to make sure that messages are sent in the correct order, only to find that the receiving system can process them out of order anyway.

Consider a Policy Created notification, which must come before a Policy Approved notification.  If both messages are sitting in the queue when the receiving service starts up, the approval message can be processed before the creation message. How can I make sure that message ordering is respected by the receiving system?  I am using WCF/MSMQ as the underlying transport by the way.  The only way I have found so far is to limit the receiving service to a single thread, which is by no means desirable.

Well, the solution is really quite simple (at first).

If you’ve received a message that you think has arrived out of order, just call:

this.bus.HandleCurrentMessageLater();

and that will put the message back at the end of the queue.

Once you start considering the fact that you don’t know when the first message is supposed to arrive, you might turn to using a workflow to handle the logic. The workflow would store the policy id, and then allow for N round-trips, before it decided that something bad had happened (like the Policy Created message getting lost), and then it could forward that to an operator, or possibly contact the first system and ask for a replay of the policy created message – or whatever automated fault resolution protocol you like.

In other words, message ordering is probably more trouble than its worth.

Since the service needs to perform all request processing in near-real-time, it caches all data from the DB in memory (yes, that’s a lot of memory). Since the service needs to handle multiple requests concurrently, we’re using multiple threads (so far, so good). The problem is that we don’t want the service to handle messages received until it’s finished caching everything. Also, we don’t want that check to show up in every message handler (important when you have lots of message types).

This is actually quite easy to do with NServiceBus. Here’s how:

Have a thread-safe class, let’s call it Loader, for the API to the caching. Something along the lines of:

If (!Loader.HasCachedEverything)
  Loader.CacheEverything();

Obviously, the Loader will have internal logic for checking if it has already started loading things from the DB, so that it won’t do the same thing twice.

OK, now on to the interesting stuff.

We’d like to have the above code run no matter which kind of message we’ve received, so we just write a “generic” message handler – which handles “IMessage” like so:

When the message handler calls “HandleCurrentMessageLater”, the bus puts the current message in the back of the queue. If you’ve configured a transactional transport, this will be safe even in the case of a server restart.

Also, notice the “CanContinue = false”. This tells the bus that the message should not be passed on to any other message handlers, even if there are those that are configured to handle it.

We’ll also package this class up by itself, keeping it separate from the core logic of the service – making it easier to version these cross cutting concerns and the service logic. Let’s put it in “CrossCuttingConcerns.dll”

The final thing needed in order to achieve the behavior described above is to configure this message handler to run before any other handler. This is done in the config file of the process, under the “bus” object, in the “MessageHandlerAssemblies” property like so:

        <property name="MessageHandlerAssemblies">
          <list>
            <value>CrossCuttingConcerns</value>
            <value>ServiceLogic</value>
          </list>
        </property>

This is similar to the way HttpHandlers are (were?) configured in IIS – the order of the handlers defines the order in which the bus dispatches messages to them.

And that’s it.

We’re done.

If you have any questions you’d like to ask about NServiceBus, please feel free to send them my way: Questions@NServiceBus.com.

And just in closing I’d like to say that I don’t necessarily think you should be creating stateful services, but that there’s a time and place for everything.

Let’s say I have a system to handle a call center for financial services or telco. When a customer calls on the phone and asks to be enrolled in “Heavily Advertised Program ABC,” there may need to be three or four systems that interact to make that real.

…

Harry asks me to consider using a ‘logical name’ of the receiver. The sender contacts a logical end point, the addressing infrastructure turns that into a physical end point, and we still have decoupling.

Honestly, I like it but I think it is insufficient. What if we need to contact 20 downstream systems in a complex workflow, but I don’t want a single “orchestration coordinator” to be a bottleneck (or single point of failure). I don’t want to hand the orchestration off from my app to a central orchestration hub.

Let me propose a different approach.

When we use SOA/EDA (the same thing as far as I’m concerned), the top-level building block used is the Service. A service may make use of a number of existing systems to perform its work. The business-level events that we publish (and subscribe to) are done by the service, not the existing systems.

If there’s any orchestration/workflow that needs to be done as a result of a service receiving an event, it is done entirely internal to that service. Inter-service orchestrations don’t really exist, as in there is no orchestration coordinator that is not in a service. And the orchestration coordinators within a service don’t touch other services’ back-end systems – if anything, they publish other business level events.

Be aware: when just starting out on an SOA, you’ll find that multiple Services make use of the same backend systems. This may be necessary, but not a desirable state to stay in for too long since it embodies the most insidious and invisible kind of inter-service coupling there is.

I want to go back to Nick’s original question:

So what if no one picks the message up? Is that an error?

The answer is mu.

If a service publishes a business-event (message) and no other services currently care, that’s fine. It’s not an error. Actually, you’d probably have some kind of infrastructure “queue” where messages that haven’t been received more than X time get sent to, so that the event isn’t “lost”. On the other hand, within a service – if an existing system sends out a message that needs to arrive at another system, and that message doesn’t arrive or isn’t picked up “in time”, that is an error.

This is one of the advantages SOA brings to the table in terms of EDA (again, the same as far as I’m concerned). You get simple messaging semantics between services, while within the “sphere of control” of a service you need, and more importantly can do more complex messaging and orchestration.

Bottom line: you need higher abstractions than your existing systems to employ EDA effectively.

You might also want to check out my podcast on this topic: SOA, ESB, and Events.

ESB’s are a lot about messaging and therefore a better name might be “Enterprise Data Bus”. It’s the asynchronous messaging that needs such an infrastructure with persistency and mediation facilities. All the WS-* standards are about messaging as well, leveraging the message itself to tell the infrastructure how it has to be handled.

I think WS-* will make it possible to have the ESB evolve from a vendor-product to a concept implemented in the operating systems an network devices that understand WS-*. Then you can leave the prefix “Enterprise” and we will be ready for an univeral asynchronous data bus over the Internet (or any other network you like). This will help breaking the current “services centric” idea of SOA into a “messages centric” perspective.

What are your thoughts?

Download via the Dr. Dobb’s site

Or download directly here.

Additional References:

• Podcast on if you need an ESB for SOA
• Podcast on Enterprise Service Discovery
• Blog post on ESBs as a global dataspace
• Blog post about what the brave new world of WS-* brings us

Want more? Check out the “Ask Udi” archives.

Got a question? Have Udi answer it on the podcast – podcast@UdiDahan.com

Q: Could you tell you your thoughts or preference for a distributed or centralized ESB?

DON: there is no such thing as a centralized ESB.

This is the problem with a lot of the products that call themselves ESBs. They are centralized brokers which may be clustered for availability. But they are in no way an implementation of the Bus Architectural Pattern. Please check this before cutting a check to your vendor.

Also, understand that if you do security related things in your ESB, possibly as a part of your routing rules, that if the security infrastructure is centralized that means your ESB is too. Even if it really was distributed to begin with.

Buyer beware.