I’ve found that when big numbers are involved, it’s important to get percentages accurate by measuring to understand the exact scope of any impact.

Next, we’re careful not to throw the baby out with the bath water. The business is the one that decides what’s worse, the extra expense of providing 100% of the users with always accurate data, or N users with degraded functionality. I have yet to see a business scaling to this many users choosing accuracy over profitability.

Finally, we look at ways to minimize the degradation of functionality - for instance, by comparing the user’s time zone with that of the location where we the cookie says they are. If there is a discrepancy, we refresh the location based on the current IP. This solves the problem for users travelling between time zones, further decreasing the number of affected users.

Rinse and repeat.

And thank you for your kind words.

The moment you bring in caching (location + weather data) you immediately create potential problems in the user experience - a good example is the “are you not in Londong?” thing that is there to actually solve a user experience problem of a user NOT being where you think he is. There are of course many other potential problems where a solution is not as easy (wrong weather data etc..).

My question is: Since these potential problems are going to affect a very minor set of customers, lets say no more then 0.5% of the customers. However, as you begin with these methods because of scalability issues as you wrote, having 10 million customers or more would mean that at least 50,000 customers would get affected.

How would you weigh the benefit of the added scalability with the “cost” of customer issues for 50,000 unhappy customers or more for which you hurt their experience compared the the tradition “web method” approach?

Thanks - Love your articles -
Ofer

You could do that, but IIS would be a really poor choice for it. Squid would be preferable.

These are the same concepts - absolutely.

http://www.martinfowler.com/bliki/SegmentationByFreshness.html

I really like the idea of composing a page from separate chunks of (cached) HTML / JSON / XML that are assembled client-side.

Based on these ideas, AJAX UI enhancements could be used to show a subset of weather data on the home page.

On 1,2,3 and 4 - that’s actually how it’s being done. The blog post was an intentional simplification to get the idea across.

On your point “Facebook has more users then this application and they are using caching tier extensively quite happily”

Well, I guess it depends on what they’re using it for

When it comes to their graph analytics, yes, that’s all being done in memory. However, that’s their core business. Weather is not this company’s core business.

Also, in an “either-or” comparison, this kind of web caching costs much less than a caching tier. That’s not to say we’re in an “either-or” situation, we can do both. That way, we shed much of the load onto the web and have much less to deal with in our caching tier.

When “everything expires”, you still don’t have all of your users requesting at the same time. The result of serving the response to one user’s request will be cached after the previous expiry for the next set of users - it’s not an issue.

And thanks for your detailed comment. It’s always great hearing from you.

Will do

Let assume following:
1) You will group weather data from several cities into logical groups (i.e. in GB you might do that according administrative regions - South West England, West Midlands, Yorkshire and the Humber, etc. For example Czech Republic as small country might be represented by only one logical group while USA might get logical groups according counties or metro regions, etc.).

2) Single logical group contains weather data for several cities - like South West England has data for Plymouth, Bristol, Gloucester, etc.).

3) User location is identified on its login as you have described above and saved via cookie. Location definition is additionally extended with identification of region (or logical group for that matter) under which user belongs (i.e. user from Bristol will get not only cookie for Bristol but also region “South West England” maybe via some index/ID). This ID is saved into cookie as well.

4) When weather data are requested then provider site send out weather data for entire region via ID and not via specific city name. User presentation will than might select detail weather info in case city name is explicitly listed in delivered data or entire region if city/town/village is not available from list.

Logical group of weather data seems to me might then get into cashing tier inside datacenter (under assumption weather data are reasonably sized) as resource consumption shall not be that big if assumed 1) “(traditional) follow-the-sun/moon” user access pattern and 2) user base is usually not distributed evenly across all countries/regions but rather “packed” in certain distinct geo-locations. Moreover you are mentioned there is multiple datacenters and therefore each datacenter might server different user geo-location which shall farther decrease resource use.

I would appreciate if you can more elaborate on cases where is reasonable to use caching tier as opposite to cases where web cache infrastructure helps well (for example Facebook has more users then this application and they are using caching tier extensively quite happily).

I’m also wondering how you can cope with situation where all “web based caching” is “not working or is expired at the same time” and designed application must serve requests directly. Would not make sense to add some kind of cashing tier to the final application anyway? It does not seem the REST might help here.

Many thanks for answers.

Regards,
Libor

Removing the [ThreadStatic] attribute causes a bug - an action on one thread by user A can call be into a different action previously registered by a different thread by user B.

The overall guidance is that the domain model with its associated events should not be called within the web app itself. Rather, the domain model should be hosted in its own process, an application server if you will, which the web app sends messages to.

Hope that helps.

“Passive kinds of data”, like countries, regions, etc were done in a similar manner.

The main difference was that they had a well known URI ahead of time as well as longer cache timeouts. Regardless, when that data was changed on the server, it would also update that resource/URI.

Love this approach. Were all the UI requests including more passive kinds of data (enumerated lists of regions for example) also handled by this single architectural approach in this scenario?

Re: How scalable would this be if large numbers of clients were requesting data in this way especially over slow connnections?

This is the way clients that don’t use pub/sub do things anyway

The answer to the rest of your question deserves a full blog post of its own, if not more than one

Here’s some:

If you can ensure that the call will be local, you can often make it synchronous.

If you suspect that a call will be remote, you should prefer to make it asynchronous / non-blocking.

Regards,
Jai

You can expose collections as IEnumerable so that there won’t be any Add/Remove methods available.

On your NHibernate specific question, you wouldn’t do anything different in the mapping to work with these interfaces. Just use Ayende’s repository wrapper around it.

Sending to your email.

I guess I should have qualified my meaning of “pub/sub” in this diagram.

When describing business services which publish events, I refer to the fact that they are not dependent upon the logical subscribers. Whether the actual data delivery is pub/sub at the network level, uses a subscription list, or client-polling is a separate (but not unimportant) concern.

One of the advantages of using this design for data which many subscribers might need is that we can leverage the caching behaviors of the internet to save on bandwidth.

All the options you outlined are also viable and technical tradeoffs need to be made between them and the design I described - a good topic for another post

The client could save the information to disk, however they may also be disconnected or off for long periods of time. You mentioned in your recent article ‘Lost Notifications? No Problem.’ that [’Publishers have no choice but to throw away messages after a certain period of time.’] What would you suggest in this situation (a differential query, P2P) or force the server to maintain the messages indefinitely (eg Outlook and Exchange)?

By locking down the set’s to internal,private, or protected you can give NHibernate special set access via the proxy but keep the entities better encapsulated.

However, I have noticed that for collections, like Lists/Bags we may lock down the setter but leave the get public. The problem here is that I can then add/remove items directly from the collection and avoid any Add/Remove methods that employ business logic.

Do you have a recommended solution to avoiding this possibility? My guess is that you would make the mapping use field level access and avoid a Property altogether.

My next issue, is NHibernate specific, so I apologize if this is outside the scope. If the desired solution is field level access, how would this work if I define my class as an interface within the mapper with concrete classes defined as subclasses? Would I have to define that particular property on every subclass?

Some options for this could be
1) Using Comet/Long Polling (http://delicious.com/mikelor/comet)
2) Using XMPP to Push Events (http://ajaxian.com/archives/beyond-rest-xmpp-pubsub)
3) Creating a Provider on Gnip (http://www.gnipcentral.com)
4) Something else, perhaps using Azure’s ServiceBus (http://www.microsoft.com/azure/servicebus.mspx)

-=mike

I think this is a great illustration of tailoring solutions to real consumer needs, which is the primary driver behind consumer-driven contracts. As a provider it may not be possible to offer a one-size-fits-all solution that meets the needs of each and every consumer - so specialize on a case-by-case basis, but in each case do “just enough” to meet real as opposed to imagined needs. Or, and this was the first motivation for CDC, if you do have to provide a one-size-fits-all contract, fit the identifiable aggregate needs, and nothing more.

When I started with CDC, it was for me really about creating and maintaining message schemas that matched the aggregate needs of several consumers - that is, a one-size-fits-all schema, but nothing gold-plated, just something with no more and no less than what was needed. We communicated consumer expectations using tests and assertions - XPath, Schematron, and more recently a representation-format-agnostic DSL (ie. expectations in this DSL can be transformed into assertions against XML, JSON, YAML, form-encoded name-value pairs, etc). By having consumer teams give these assertions and tests to provider teams, we helped providers build into their own test suites and continuous integration environments an understanding of how their services were actually being used. If tests were kept up-to-date, teams could then track their schema footprint and identify possibly redundant elements. Where we were able to do this early enough in the service development lifecycle, these programmatic expectations helped drive out a service contract “by example”.

So I guess CDC started out as a way to help the one-size-fits-all mentality do the simplest thing that could possibly work, whilst at the same time providing a basis for evolving a service as new expectations and consumer needs were identified and came online. I’m always on the lookout for practices and techniques that allow us to do just enough today - even in the context of SOA - whilst maintaining a duty of care to the overall lifetime of a system, and this seemed to help.

CDC then, in its original form was quite modest, being concerned mainly with schema and a desire to contain proliferation - ie. not stamp out consumer-specific instances of a message but instead provide a minimally complete single instance. But with experience I’ve learnt there is a case for specializing what a provider has to offer on a consumer-by-consumer basis - and I think this is an equally, if not more, interesting real-world application of the idea. I remember Jesus Rodriguez did something with the WCF LOB adapters along these lines quite some time ago. Your varying the publication rate, message size and transport per consumer is another good case in point. Inside ThoughtWorks, Jim Webber and I did something similar with a client at the beginning of the year. As with your case, it involved BI. Recognizing that BI consumers have quite different needs - and capabilities - from “transactional” consumers, we created a specialized ETL-friendly interface to our service that extended and clarified our business-meaningful service contract in line with a real-world need. As with what you describe, consumer expectations, including quality-of-service expectations, shape the service ecosystem to the problem at hand, rather than compromising the solution by adapting the problem to a narrow, ostensibly consistent but less-than-useful architectural or technical vision.

Hope this is of some help. On a more general note, your blog and articles have been enormously useful in shaping, testing and refining my own approach to delivering on SOA initiatives over the last few years. Over and against a certain 3-layer-application-architecture-blown-out-to-distributed-proportions school of SOA, your writing, together with Bill Poole’s stuff, which I think I probably found through your blog, steers a far more valuable course.

Kind regards

ian

In particular I think taking a simple example (such as in http://www.udidahan.com/2008/11/01/soa-eda-and-cep-a-winning-combo/) and breaking it down into automonomus/business components would really make this stuff concrete.

Glad you liked it.
If/when Microsoft makes it available online, I’ll definitely link to it.

Glad you liked it.
And never underestimate the power of the lone ranger

Nice presentation and thanks for sharing it. Can I get audio part of this presentation. Appreciate all your sharing and keep up the great work.

Thanks
Ram

Congratulations, your post is the clearest view relating the combined use of SOA and EDA principles for Information systems specification I have ever seen. I am a “lonesome cowboy” fighting in the arena of a Telco operator and talking alone about EDA in the last years. Your clear objective view of the benefits of EDA + SOA and their complementary role will be determinant to open some minds around here. Thanks.
Mário Rui da Costa
of

I’m not sure if the TechEd guys will make the recording publicly available, but you can hear some of the content from the podcast I did at TechEd USA.

You can find that here.

The webcast is now online.

I’ve posted the link here.

My service layer usually does messaging - those “special Message Objects” you alluded to (which are DTOs).

You might like this post describing how these two might work together in a broader perspective here:

Command Query Separation and SOA

I accept that you have a different opinion on the definition of “service” than I do. Apparently, it’s not just the two of us - everyone has their own definition

For me, I’ve given up on the whole reuse thing. I think it’s a crock. Has been since OO.

Also, as the example in my post describes, we can see the same thing being both an event producer and “reaction process” as you call it for different kinds of events.

I’ve read the posts you linked and it appears that you take an integration perspective on SOA. I perceive integration as something that occurs within the context of a single business service.

Anyway, glad you commented and I’m looking to hearing more from you.

This creates extensibility and maintainability issues.

Suppose I write another domain object which acts as an aggregate root in a different scenario making use of the current parent as a child. I’d have to remember to redefine that event on my object.

Does that make sense?

We need more people fighting the good fight

Glad you liked it.

-Jack

Good post! I totally Agree with this idea. SOA is a good pattern to clearly separate the different responsibilities within the application Then use EDA to have these Services communicate with each other. This gives a very high grade of louse coupling and with that all the nice abilities to make changes easier. I have been thinking about combining EDA with DIP as a technical pattern with the main purpose to make change easy (http://blog.fohjin.com/2008/09/no-dependency-architecture-nda.html). Adding SOA to this seems like a logical next step, I will definitely look more into this.

Thanks,

-Mark

What would be the problem with that?

Foreign keys and unique constraints are still enforced in the DB. The web server, by having a copy of emails locally, can avoid calling through to the DB for user registrations which are clearly invalid. Still, the web server doesn’t add users on its own volition, but submits a request through to the DB for that.

The point of this web tier caching is to reduce load on the DB, not to replace it entirely.

There are cases where “things can’t be made asynchronous”, but less than you might think. I do have guidelines around them, but they fill up a 5-day course and are very much tied to understanding the specifics of your business domain.

Hope that helps.

http://soa-eda.blogspot.com/2006/11/how-eda-extends-soa-and-why-it-is.html

-How are foreign keys and unique constraints handled in this setup? For example, if there is a unique constraint on email in the database, but the web server allowed a user to register the same email twice. Is it expected that all such constraints should be enforced in the service in addition to the database?

-Are there, in fact, cases where “things can’t be made asynchronous”? When designing a system, do you have any guidelines for when to/not to use nServiceBus and event-driven design?

Imagine case where Sales let client order varies items. Upon order request confirmation is order data passes to Billing which creates invoice and returns it back to Sales. Billing also passes request to Shipping for packaging items. Sales collect all documents from Billing and Shipping and passes them on client -> either all was confirmed or order was reject for some reason (i.e. out of stock items, user broke credit line, etc.).

Main question is: Would you still use pub/sub in all those communications? If not why and when you would use it then.

If I would get assignment as described above I would probably think first about replacing synchronous calls with async. once. MSQM/REST or similar helps nicely here.

Additionally I would think Merchandising and Sales need to “know each other”. What you will do if subscriber (i.e. Sales) misses some price update sent from publisher due its own downtime (this under assumption that price is published only when changed and not periodically even if not changed)? For this reason I would say there has to be some way Sales will ask Merchandising to ask for “snapshot” on possibly missed data or get up-to-date price data. And here we have basically request/response pattern. MSMQ/Rest would help again.

Yes I need explicit configuration for both services to talk to each other. If I’m on enterprise system I would not see any problem with it.

From article there is nothing which indicates you are planning to use published prices in another service.

Planning for use same data on multiple services seems to be a good reason for pub/sub. But if I originally use MSMQ for solution (i.e. async mode delivery) to connect “M” & “S” services and now I have additional services which needs price notification I can just simply use “Distribution list” feature here (http://msdn.microsoft.com/en-us/library/ms704262(VS.85).aspx). And again I have to admit that explicit destination setup is needed. But is it really problem especially in case of enterprise solution if basically know all subscribers? BTW need for request/response pattern on snapshot remains still here.

On the other hand, how would Merchandising know that Sales needs its price information? This logical coupling is what pub/sub avoids, on top of the physical coupling that one-way messaging avoids.

Should an additional service want pricing and/or product information, it could just subscribe to those events, without requiring any changes to Merchandising.

Does that make things clearer?

What is major benefit of pub/sub here compare for example with plain message queuing (e.g. MSMQ with persistence which addresses disconnected states quite well)?

Additionally I don’t think asynchronous call automatically means RPC (i.e. I assume RPC is defined as blocking operation on caller side). I can send (as Merchandising via async. call) given price notification as easily as you do with pub/sub and don’t need to block itself on response.

That still has the unfortunate effect that the end-to-end time it takes to process a call is dependent on the speed of who you’re talking to. Pub/sub eliminates that as well.

But thanks for helping me focus on the actual benefit pub/sub brings over RPC and asynchronous calls.

For example in first paragraph under section “Pub/Sub Considered Helpful” I might replace “pub/sub” with “asynchronous call”, “published” with “send” and “publisher/subscriber” with “provider/consumer”. Sentence with change remains still true.

Are you referring to how Sales gets pricing information from Merchandising?

Regards,
Libor

That’s correct.

Glad you liked the slides so much.
I’ll get in touch with IASA and see if the recording is online.

By any chance was there a webcast for this talk ? I would like to get my hands on it if one was recorded.

Very good slides, I must admit.

Cheers

I don’t consider this an issue. If you can do everything you need by calling a single (one and only one) method on the interface which you retrieved (it’s OK to pass in other objects which you retrieved or created as parameters), then you should be fine.

I’m quite new to DDD and something I have recently been contemplating (and battling with) is a rule suggested in Evan’s book that only Aggregate Roots can be obtained directly with database queries, everything else must be done through traversal.

In the example above (and in many attempts I have made to use the repository pattern with a generic repository), it seems appropriate to request an implementation of an interface that isnt the (necessarily) the implementation of your aggregate root.

The example code requests and returns an implementation of IOrderCalculator from the repository. This may or may not be the aggregate root (order). Do you see this as an issue?

Ayende’s new repository bundles this behavior into it directly. Use it

I think that that’s about right.

Saying “we have tests” is relatively worthless, saying we have our core logic fully tested and can now refactor or evolve safely has immense value.