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]

“A common complaint is that the first call on a client object takes some disproportionately large amount of time, usually ten seconds or more, while successive calls are instantaneous. There are many reasons why this might happen so there’s no generic resolution for this problem.” — Nicholas Allen

The thing is that there IS a generic solution to this problem.

It’s queued messaging.

The only thing is that you have to give up talking to your services as if they were regular objects – calling methods on them and expecting a response. In other words, designing a distributed systems isn’t like designing a regular OO system just with some WCF sprinkled on top.

Even when trying to do fire and forget messaging on top of WCF (void method calls with the OneWay attribute), the underlying channel can still block your thread, as Nick mentioned.

A queue isn’t an implementation detail.
It’s the primary architectural abstraction of a distributed system.

I’ve been to too many clients where I’ve been brought in to help them with their problems around service versioning when the solution I propose is simply to have version N+1 of the system be backwards-compatible with version N. If two adjacent versions of a given system aren’t compatible with each other, it is practically impossible to solve versioning issues.

Here’s what happens when versions aren’t compatible:

Admins stop the system from accepting any new requests, and wait until all current requests are done processing. They take a backup/snapshot of all relevant parts of the system (like data in the DB). Then, bring down the system – all of it. Install the new version on all machines. Bring everything back up. Let the users back in.

If, heaven-forbid, problems were uncovered with the new version (since some problems only appear in production), the admins have to roll back to the previous version – once again bringing everything down.

This scenario is fairly catastrophic for any company that requires not-even high availability, but pretty continuous availability – like public facing web apps.

If adjacent versions were compatible with each other, we could upgrade the system piece-meal – machine by machine, where both the old and new versions will be running side by side, communicating with each other. While the system’s performance may be sub-optimal, it will continue to be available throughout upgrades as well as downgrades.

This isn’t trivial to do.

It impacts how you decide what is (and more importantly, what isn’t) nullable.

It may force you to spread certain changes to features across more versions (aka releases).

As such, you can expect this to affect how you do release and feature planning.

However, if you do not take these factors into account, it’s almost a certainty that your versioning problems will persist and no technology (new or old) will be able to solve them.

Coming next… Units of versioning – inside and outside a service.

My article on “optimizing a large-scale Software+Services application” has been published in the April edition of MSDN Magazine.

Here’s a short excerpt:

“We had to juggle occasional connectivity, data synchronization, and publish/subscribe all at the same time. We learned that we couldn’t solve all problems either client-side or server-side, but rather that an integrated approach was needed since any changes on one side needed corresponding changes on the other side.”

Continue reading…

On Web 2.0 Mashups

One would think that sites like Weather.com and friends would be the first choice for implementing such a feature. Only thing is that they were strongly against being mashed-up Web 2.0 style on the client – they had enough scalability problems of their own. Interestingly enough (or not), these partners were quite happy to publish their weather data to us and let us handle the whole scalability issue.

Implementation 1.0

The current implementation was fairly straightforward – client issues a regular web service request to the GetWeather webmethod, the server uses the user’s IP address to find out their location, then use that location to find the weather for that location in the database, and return that to the user. Standard fare for most dynamic data and the way most everybody would tell you to do it.

Only thing is that it scales like a dog.

Add Some Caching

The first thing you do when you have scalability problems and the database is the bottleneck is to cache, well, that’s what everybody says (same everybody as above).

The thing is that holding all the weather of the entire globe in memory, well, takes a lot of memory. More than is reasonable. In which case, there’s a fairly decent chance that a given request can’t be served from the cache, resulting in a query to the database, an update to the cache, which bumps out something else, in short, not a very good hit rate.

Not much bang for the buck.

If you have a single datacenter, having a caching tier that stores this data is possible, but costly. If you want a highly available, business continuity supportable, multi-datacenter infrastructure, the costs add up quite a bit quicker – to the point of not being cost effective (”You need HOW much money for weather?! We’ve got dozens more features like that in the pipe!”)

What we can do is to tell the client we’re responding to that they can cache the result, but that isn’t close to being enough for us to scale.

Look at the Data, Leverage the Internet

When you find yourself in this sort of situation, there’s really only one thing to do:

Leverage the Internet

The internet is the biggest, most scalable data serving infrastructure that mankind was lucky enough to have happen to it. However, in order to leverage it – you need to understand your data and how your users use it, and finally align yourself with the way the internet works.

Let’s say we have 1,000 users in London. All of them are going to have the same weather. If all these users come to our site in the period of a few hours and ask for the weather, they all are going to get the exact same data. The thing is that the response semantics of the GetWeather webmethod must prevent intermediaries from caching so that users in Dublin and Glasgow don’t get London weather (although at times I bet they’d like to).

REST Helps You Leverage the Internet

Rather than thinking of getting the weather as an operation/webmethod, we can represent the various locations weather data as explicit web resources, each with its own URI. Thus, the weather in London would be http://weather.myclient.com/UK/London.

If we were able to make our clients in London perform an HTTP GET on http://weather.myclient.com/UK/London then we could return headers in the HTTP response telling the intermediaries that they can cache the response for an hour, or however long we want.

That way, after the first user in London gets the weather from our servers, all the other 999 users will be getting the same data served to them from one of the intermediaries. Instead of getting hammered by millions of requests a day, the internet would shoulder easily 90% of that load making it much easier to scale. Thanks Al.

This isn’t a “cheap trick”. While being straight forward for something like weather, understanding the nature of your data and intelligently mapping that to a URI space is critical to building a scalable system, and reaping the benefits of REST.

What’s left?

The only thing that’s left is to get the client to know which URI to call. A simple matter, really.

When the user logs in, we perform the IP to location lookup and then write a cookie to the client with their location (UK/London). That cookie then stays with the user saving us from having to perform that IP to location lookup all the time. On subsequent logins, if the cookie is already there, we don’t do the lookup.

BTW, we also show the user “you’re in London, aren’t you?” with the link allowing the user to change their location, which we then update the cookie with and change the URI we get the weather from.

In Closing

While web services are great for getting a system up and running quickly and interoperably, scalability often suffers. Not so much as to be in your face, but after you’ve gone quite a ways and invested a fair amount of development in it, you find it standing between you and the scalability you seek.

Moving to REST is not about turning on the “make it restful” switch in your technology stack (ASP.NET MVC and WCF, I’m talking to you). Just like with databases there is no “make it go fast” switch – you really do need to understand your data, the various users access patterns, and the volatility of the data so that you can map it to the “right” resources and URIs.

If you do walk the RESTful path, you’ll find that the scalability that was once so distant is now within your grasp.

For comparison later, here’s a diagram showing the trivial interaction:

One solution that he’d tried was to set up the web server to throttle those requests and keep a much smaller maximum thread-pool size for that application pool. The unfortunate side effect of that solution was that clients would get “turned away” by a not-so-pleasant Connection Refused exception.

Will had been to my web scalability talk and was curious about how I was using queues behind my web services. I’ve also heard this question from people just getting started with nServiceBus when looking at the Web Services Bridge sample. Here’s the code that’s in the sample and in just a second I’ll tell you why you shouldn’t do this:

[WebMethod]

public ErrorCodes Process(Command request)

{

    object result = ErrorCodes.None;

    IAsyncResult sync = Global.Bus.Send(request).Register(

        delegate(IAsyncResult asyncResult)

          {

              CompletionResult completionResult = asyncResult.AsyncState as CompletionResult;

              if (completionResult != null)

              {

                  result = (ErrorCodes) completionResult.ErrorCode;

              }

          },

          null

          );

    sync.AsyncWaitHandle.WaitOne();

    return (ErrorCodes)result;

}

Let me repeat, this is demo-ware. Do not use this in production.

What’s happening is that in this web service call we’re putting a message in a queue for some other process/machine to process. When that processing is complete, we’ll get a message back in our local queue (which you don’t see) which is correlated to our original request, firing off the callback. We block the web method from completing (using the WaitOne call) thus keeping the HTTP connection to the client open.

The problem here is that we’re wasting resources (the HTTP connection and the thread) while waiting for a response which, as already mentioned, can take a long time. In B2B or other server to server integration environments there are all sorts of middleware solutions that help us solve these problems, however in Will’s case browsers needed to interact with this web service. All he had was HTTP.

HTTP Solutions

Another attendee who was listening in (sorry I don’t remember your name) said that he was solving similar problems using polling but that he was having scalability problems as well.

What often surprises my clients when we deal with these same issues is that I do suggest a polling based solution, but one that still uses messaging, and this is what I described to Will:

Since we can’t actually push a message to a browser over HTTP from our server when processing is complete, the browser itself will be responsible for pulling the response. We still don’t want to leave costly resources like HTTP connections open a long time, however if the browser is going to polling for a response, we’ll need some way to correlate those following requests with the original one. What we’re going to do is use the Asynchronous Completion Token pattern, and later I’ll show how to optimize it for web server technology.

Basic Polling

When the browser calls the web service, the web service will generate a Guid, put it in the message that it sends for processing, and return that guid to the browser. When the processing of the message is complete, the result will be written to some kind of database, indexed by that guid. The browser will periodically call another web method, passing in the guid it previously received as a parameter. That web method will check the database for a response using the guid, returning null if no response is there. If the browser receives a null response, it will “sleep” a bit and then retry.

One of the problems with this solution is that polling uses up server resources – both on the web server and our DB; threads, memory, DB connections. A better solution would decrease the resource cost of the polling. Let’s use the fundamental building blocks of the web to our advantage – HTTP GET and resources:

REST-full Polling

Instead of using a guid to represent the id of the response, let’s consider the REST principle of “everything’s a resource”. That would mean that the response itself would be a resource. And since every resource has a URI, we might as well use that URI in lieu of the guid. So, instead of our web service returning a guid, let’s return a URI – something like:

http://www.acme.com/responses/88ec5359-a5d8-4491-a570-3bfe469f3a64.xml

As you can see, the guid is still there. So, what’s different?

What’s different is that instead of having the processing code write the response to the database, it writes it to a resource. This can be done by writing some XML to a file on the SAN in the case of a webfarm. Also, the browser wouldn’t need to call a web service to get the response, it would just do an HTTP GET on the URI. If the it gets an HTTP 404, it would sleep and retry as before. The reason that the SAN is needed is that, as the browser polls, it may have its requests arrive at various web servers so the response needs to be accessible from any one of them.

Just as an aside, it would be better to free the processing node as quickly as possible and have something else write the response to the SAN. That would be done simply by sending a message from the processing node that would be handled by a different node that all it did was write responses to disk.

The reason that the URI makes a difference is that serving “static” resources is something that web servers do extremely efficiently without requiring any managed resources (like ASP.NET threads). That’s a big deal.

We’re still using HTTP connections for the polling but that’s something whose effect can be mitigated to a certain degree.

Timed REST-full Polling

Since various requests can take varying amounts of time to process, it’s difficult to know at what rate the browser should poll. So, why don’t we have the web service tell it. As a part of the response to the original web service call, instead of just returning a URI, we could also return the polling interval – 1 second, 5 seconds, whatever is appropriate for the type of request. This value could easily be configurable [RequestType, PollingInterval].

An even more advanced solution would allow you to change these values dynamically. The advantage that would be gained would be that your operations team could better manage the load on your servers. When a large number of users are hitting your system, you could decrease the rate at which your servers would be polled, thus leaving more HTTP connections for other users.

Scaling and Adaptive Polling

You’d probably also want to scale out the number of processing nodes behind your queue. The nice thing is that you could change the polling interval as you scale the various processing nodes per request type providing better responsiveness for the more critical requests. Once we add virtualization, things get really fun:

We had separate queues per request type, so that we could easily see the load we were under for each type of request. That way, we could scale out the processing nodes per request type as well as change the polling interval. By virtualizing our processing nodes, and writing scripts to monitor queue sizes, we had those scripts automatically provisioning (and de-provisioning) nodes as well as changing the polling interval of the browsers.

This had the enormous benefit of the system automatically shifting resources to provide the appropriate relative allocation for the current load as its macroscopic make-up changed.

Summary

Will was well-pleased with the solution which, although more complicated than what he had originally tried, was flexible enough to meet his needs. As opposed to pure server-based solutions, here we make more use of the browser (writing our own Javascript) instead of putting our faith in some Ajax-y library. That’s not to say that you couldn’t wrap this up into a library – in essence, it is a kind of messaging transport for browser to server communication allowing duplex conversations.

In fact, what could be done is to return multiple responses to the browser over a long period of time. In the response that comes back to the browser could be an additional URI where the next response will be. This can be used for reporting the status of a long running process, paging results, and in many other scenarios.

And, one parting thought, could this not be used for all browser to web service communication?

Check it out.

Some of this stuff is a bit counter-intuitive (and not readily supported by the tools available in Visual Studio) so please, do feel free to ask questions (in the comments below).

Note to those who didn’t attend the session: you didn’t hear me say it, so I’ll repeat it: I hate WSDL almost as much as I hate Las Vegas. Ask me why sometime, or if I get enough of a critical mass of questions, I’ll blog it. If you’ve seen me do talks on Web Services, though, you’ve probably heard the rant: WSDL creates tightly-coupled endpoints precisely where loose coupling is necessary, WSDL encourages schema definitions that are inflexible and unevolvable, and WSDL intrinsically assumes a synchronous client-server invocation model that doesn’t really meet the scalability or feature needs of the modern enterprise. And that’s just for starters.

I hate WSDL.

I still hate Vegas more, though.

Web Services, and WSDL by connection have taken hold of the industry like cancer – inhibiting the minds of otherwise intelligent developers and architects. Whenever I get the “Web Services Question” (Does X support Web Services – where X is some design pattern, tool, and sometimes nServiceBus), I have to suppress an urge to groan – I’ve got the question that many times. The other day I was at a client and Sam, their head architect asked me that question. I gave my stock response:

“When you say ‘Web Services’, are you referring to SOAP or WSDL, and is HTTP a necessary component too?”

See how good I got at the suppressing thing?

Sam conceded that Web Services over TCP is OK too, so I pressed on with:

“What about UDP? FTP? MSMQ? Is it still ‘Web Services’ then? Is the rule then that ‘Web Services’ == SOAP?”

At that point, Sam was beginning to get a little flustered.

“And what’s so great about SOAP? Is it the interoperability? Because that’s just because it’s based on XSD.”

He didn’t know how to reply. Instead, he walked away from the whiteboard and sat down. I didn’t let up:

“And what if we want to do something other than Request/Response? How about one request with many responses? How about many requests and one response? And why does this decision need to be rigid? Shouldn’t we just be able to decide programmatically how many responses we want to return? Wouldn’t that flexibility be better than creating huge response structures for web methods to return?”

Sam made his last stand:

“Look, we can’t go and do something different from the rest of the industry. Everybody else is doing Web Services. It’s not like the technology doesn’t work.”

I gave way, a little:

“If you want, we can offer two interfaces. One, the flexible, robust, scalable XSD over messaging based solution. The second, an icky, synchronous Web Services facade which calls into our first interface.

I’m not saying that the technology doesn’t work – but both of us know that every problem has multiple solutions, some are fragile and error prone like WS, others are more elegant and have decades of knowledge behind them like messaging.

But we can do both if you like. How’s that?”

And it was agreed. The entire system would be built on one-way messaging patterns using XSD in cases where interoperability was required. And WS would be layered on, like a tiny little pig on top of a gigantic lipstick … thing – hmm, that metaphor isn’t really working – well, you get the idea.

I hate WSDL. Never been to Vegas, though.

NServiceBus Tutorial

I gave a full day tutorial on nServiceBus and we had a full house! The tutorial was about 90% how to think about distributed systems, and 10% mapping those concepts onto nServiceBus. I made an effort to cram about 3 days of a 5 day training course I give clients into one day, but I think I was only about 85% successful. People didn’t have the time needed to let things really sink in and ask questions, but the lively forums and skype conversations available will probably do the trick.

Jim Webber after looking at the unit testing features of nServiceBus had this to say:

“Oh my God – you’ve created testable middleware! It’ll never catch on. The vendors won’t have it.”

To which I replied that several vendors were already coming on board with their own implementations of transports and saga persistence. I have absolutely no intention, desire, or (quite frankly) the ability to write an enterprise-class middleware runtime. All I hope to do with nServiceBus is to make it so that developers use what’s out there in one, middleware-product-agnostic way that will make their code more robust and flexible.

MEST & Mark – REST & Stefan

It was also great finally meeting the head MESTian, Mark Little, who also happens to work for Redhat as SOA Technical Development Manager and Director of Standards in the JBoss division. It was interesting to see the difference between how I went about messaging in nServiceBus (full peer-to-peer including pub/sub) whereas most of the Java world has the messaging infrastructure handled by something database-like in a deployment/networking kind of perspective. If that’s the way things are done, then I can definitely appreciate the advantages of Space-Based Architectures.

And I even got to steal Stefan Tilkov’s RESTful ear for an hour or so before I had to jet back home. It looks like we MESTians and RESTians can be one big happy family. I’m guessing that our despise of WS connects us all at a deeper level

Core Design Principles

I also gave a talk about core design principles, “Intentions & Interfaces – making patterns concrete”, and it went over very well especially considering that that was the first time that I gave that talk. You can find the slides here. From the feedback I heard after the talk, I think many people were surprised how many different parts of a system can be designed this way, and how flexible it is without making the code any more complex. The message was this:

Make Roles Explicit

Despite its simplicity, that leads to IEntity, IValidator<T> where T : IEntity, (which I wrote about a year ago – generic validation) and with a bit of Service Locator capabilities, you can add a line of code to your infrastructure that will validate all entities before they’re sent from the client to the server.

It leads to IFetchingStrategy<T> for improved database loading performance (also a year old – better DDD implementation and the NHibernate implementation).

It’s also how nServiceBus does message handling – IMessage, IMessageHandler<T> where T: IMessage, ISaga<T> where T : IMessage.

San Francisco?

Just a quick shout to my readers in the San Francisco area, if you’d be interested in hearing these talks/tutorials, give the organizers of QCon a shout and they’ll bring me out. That’s actually what got me to London – one of the attendees of a talk I gave at Oredev in Sweden last November missed my tutorial there so he put in a request and that did it. (Thanks Jan, I appreciate it!)

If you’re in a different part of the world and you’d like to have me give one of these talks, or other ones (I have a fair amount of material on Domain Models/DDD and Occasionally Connected Smart Clients), I’d be happy to make the trip and see you there as well.

Download

Download via the Dr. Dobb’s site

Or download directly here.

Additional References

• Podcast: “REST vs Web Services Debate”
• REST Definition
• Roy Fielding’s Thesis: “Architectural Styles and the Design ofNetwork-based Software Architectures”
• ETag Definition

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

By the way, if you’re looking for more Q&A style info, check out the Ask Udi podcast. If you have a pressing question and need a shorter turn around time than the month or so it usually takes me for the podcast, send me an email to OnlineConsultation@UdiDahan.com.

Number 1

Ron: Hey, welcome back to ARCast Rapid Response. This is your host Ron Jacobs and today I’m looking at the MSDN architecture forum where I see this message from “theking2.” Yeah? OK, so “king,” he says, he’s building a distributed architecture that has a number of external systems. These external systems interface through a telnet connection and so they accept commands and return results as ACKS or NACKS.

Typically these systems have limited resources for the number of simultaneous sessions you can open, so, five to fifty depending on the system. What he did to get around this, was, he created some Enterprise Services objects and some pooled objects that set up these connections and then he has some Web services. The Web services are going to receive an incoming message. They’re going to call these pooled COM+ objects and they’re going to make the telnet calls to the external systems. Sounds interesting.

He says, after a year of production it has become apparent that some of the external systems are not performing very well. He says the bulk of the requests, but not all, to the external systems can be done asynchronously. So, he’s opting for a message queue-based solution using pseudosynchronous calls whenever a direct response is needed.

So, the question is, at what layer would message queuing make most sense?

So, should the clients, this Web service that receives the message — should it do a queue? Put a message in the queue and then the COM+ objects would pop off or they have some central Web services that would pop it. So, the central Web services or these Enterprise Service objects? Or maybe just a communication at the top of the telnet. He says this is the first time when he’s using message queuing.

On the line with me I have Udi Dahan, the Software Simplist from Israel.

Udi, this is a very interesting application and my first gut reaction is, does it really matter where you put the queuing?

Udi Dahan: Well, actually I took a look at it as well and I’d have to say that it does because the problem that he’s trying to solve isn’t that clear. We know that there is some sort of performance problem but we’re not quite sure where it is. We know that there are long and varying latencies in the responses but we’re not really quite sure why.

While we know that their external system is a bit slow but our choice of where to put the queue will probably have an impact, obviously on the development model of the clients and the Web services as well as how those external systems would work. So, I’d have to say that choosing the correct place to put the queue is important.

Ron: Well, let me interject something here because what you said just made me think. Now, if the problem is that these external systems are slow and limited number of connections, the first question we ought to ask is, does queuing help this situation at all?

Udi: Well, that’s probably a good first step. I mean every single time someone comes with a solution and then says, “OK, what’s the problem,” it’s always a good thing to check that solution first.

It looks like the problem that he has here has to deal with or the reason that he wants to use a queue is to do some kind of load leveling. He’s getting too many requests or at too high a rate from his clients and external Web services and external web applications more than his back end systems can use. So, using a queue as a load leveling mechanism is definitely the right way to go. So, from that perspective I think that putting a queue somewhere in there is a good idea.

Ron: OK. So then if you put a queue, it seems to me that it’s not going to make that much difference which layer you put the queue, would it?

Udi: Well, it might for the main reason that you really have to look at where his bottleneck is and that’s his back end systems. The bottleneck also has to do with the number of connections that can be opened and the number of sessions that can be opened. The place that I’d be looking at doing that is probably between those pooled COM+ objects and his central Web services for the main reason that that really gives a nice encapsulation in terms of the Web services towards both his organization’s internal services if they are other Web services, web applications or clients and everybody else that’s going on out there while keeping that abstraction out of the way.

So, the choice of using pooled COM objects is one of the ways he does the load leveling now. One of the problems he has is that it doesn’t seem to be doing that much for him because the switches and knobs that are available in COM+ in order to do that load leveling aren’t that great. What I’d be looking at in his situation is to put a queue in there but on the back side of that queue, not talking directly to the external system but doing something with WCF.

WCF has an incredible amount of switches and knobs in order to do the load throttling and the number of threads that are open. He could also do that on a large number of URIs in order to sort of split up the load from that perspective allowing him to cache results quite a bit better. So, that’s where I’d be looking at too. Just throw away those COM+ objects, put WCF in there, use the MSMQ binding and start configuring things from there.

Ron: There’s a lot of stuff in the message, but I think his core concern is performance. He mentions pseudosynchronous calls. I think by that he means, a message comes in to the web service, he’s going to drop something on the queue and then hold that message response until he gets a response back from a queue. So, it’s sort of synchronous but sort of not synchronous. So, in effect he’s kind of waiting on a queue instead of waiting on the pooled object to make this outbound telnet call.

I could agree if you said, “Well, look, our big problem is that we keep getting time outs because when we go to get a COM+ object from the pool, COM+ waits for a while and then it says, “Hey, there’s no object available’ and it returns an error,” then the queue is definitely going to help that problem. But in terms of the sheer through put or performance of the system, this is not going to help at all. It’s going to still be the same performance.

Now if you said, “Oh look, we can do some of this work kind of at a later point in time, ” well queuing doesn’t allow you to time shift the work. Right? So, if you said, “Look we can rethink this solution.” So you get a message in, we stuff something in a queue that we’ll deal with later, and then very quickly return a response like some kind of a number like, hey “your transaction number blah, blah, blah, will be processed later, it’s queued for processing, ” whatever.

I mean that introduces a lot of complexity in the system but it clearly would provide better response at the Web service layer. What do you think?

Udi: Well I think that at the most basic level, his throughput is dictated by his back end systems. From what he seems to be describing, every single request that is going through there, has to hit that back end system. If he has a limited number of back end systems that are supporting a limited number of connections, that’s going to limit his throughput no matter what technology he puts in front of that. So that’s at the core level. You just can’t get away from that.

The one thing that I would agree with you in your description there is the choice of using those COM+ objects. I mean COM+ was a great technology when it came out. The problem occurs, of course, when we start getting into larger and larger delays around the response time and we start getting all sorts of time out exceptions and things like that. So in that respect, I definitely say you know, take a step back from there.

But in terms of everything that he has around there, the queue isn’t going to make the back end system run any faster. What it will do is definitely complicate his system because he’s taking something that used to be synchronous and making it asynchronous. Writing Web services in order to handle that, I mean just adding a bunch of threads in order to listen to queues is not going to make things any simpler.

However, what it might do is to improve the resource usage of those Web services, OK? So instead of having those Web services have a bunch of threads open, waiting for the response coming back from those COM+ pooled objects, those threads could be relinquished and really just be triggered back up when a response comes back from the queue.

So I don’t see an improvement in the kind of solution that MSMQ or queuing would put in there in terms of the latency — how long it would take for a response to get back. However, I do see an improvement in terms of the resource usage of all the other players in the system.

Ron: I would agree with that. I would just say though that if you make the Web server that is hosting these Web services more resource efficient, maybe all you’re going to do is enable it to get more requests in queue the more quickly. Ultimately, this solution I think is going to solve a lot of problems related to time outs and server busy errors and that sort of thing, thread contentions, but not likely to increase overall performance.

But I definitely agree though. I would move this solution forward to WCF. I used to be on the COM+ team. COM+ was rolled into WCF so that it would have similar capabilities for pooling, instancing behavior, transactional support, those sorts of things. I would definitely move that forward into WCF.

OK! So great answer, Udi. Thank you so much for being on this ARCast Rapid Response.

Number 2

Ron: Hey this is Ron Jacobs back with another ARCast.TV Rapid Response. Today I’m joined by Udi Dahan, the Software Simplist from Israel.

Udi, I’m looking at the MSDN Architecture Forum and here’s a question from “blast.” Blast says he’s looking for where to put business rules. He’s developing a WinForm application. He uses data sets as the data layer, he says. He’s thinking about business rules and where to put them.

He says obviously, the more organized and centralized business rules are, the better. He’s tempted to put the business rules in the UI layer especially with the type data set. It makes a lot of sense there but not all rules belong on the client. He says some rules belong on the server, perhaps in a trigger.

So he’s asking where do you put your rules? How do you think about this problem, Udi?

Udi: Well, it looks like what he’s doing here is developing a two-tier client that is using WinForms and using datasets and speaking directly to the database. That in essence is part of his problem in that in terms of performance, he’d like to run more rules in the UI layer so that the user won’t be sending garbage to the database.

He also understands that because he’s building a multi-user system, there is a limited capability, in terms of concurrency, of actually having all the rules run correctly in order to make sure that everything is correct. So, his choice of an architecture, working two-tier is the main problem of why he has to fragment his business rules.

If he were to move towards a three-tier solution, that is put an application server between his smart client and the database, it would be a lot easier to put those business rules there. Now, once the business rules are out of the database, because again, we don’t have to deal with the concurrency issues once we have an application server and we’re using transactions there and we don’t have any disconnected problems, then what we can do is use those same DLLs, that same CLR code that runs the business rules, and deploy it client-side and use it there.

So, in terms of deployment, what we’d have is we’d have the same rules, both running client-side and server-side, whereas from a development perspective, we’d have them organized and centralized. That’s the way that I’d go about it.

Ron: Yeah, you know, I think conceptually I agree with you that a multi-tier solution would be a very good idea here. What I would probably think about conceptually, is breaking down rules into things that really ought to happen on the client-side. In particular, rules related to validation of data, so you know that you’ve got good and complete data before you ship it off to the server-side. Oftentimes you have to do that anyway because you have a button that shouldn’t be enabled until the data is valid, or something like that.

Udi: Absolutely.

Ron: Of course, we all know that if you have middle-tier web services, you must do validation both on the client-side and the server-side, because you must ensure that the valid data is received on the web server. So I agree with you that creating an assembly that you deploy on both sides is a good idea.

I would just expand on what you said a little bit and think about maybe on the server-side using a workflow foundation and business rules and workflow as a way to handle a lot of the heavier lifting, server-side validations and business rules that might require maybe sifting through more data or whatever kind of things, but server-side business rules that are more oriented towards business logic, and even if you have very, very data-intensive roles, then maybe some of those might even happen in the database. Don’t you agree?

Udi: Oh, absolutely. Absolutely. That’s something that I think often gets swept under the rug too much. Things like unique constraints and things like that are kinds of business rules. They protect the referential integrity and if we look at the alternatives, sometimes getting 10 million rows out of the database, in order to do some sort of unique email validation upon them, that’s just going to kill your performance.

There are certain things that it just makes sense to do them in the database, it’s just the best way to do it. The hard part, from a development perspective, is maintaining the coherence of your business rules. When you say, “OK, I want a single perspective, what are all the rules in my system?”

Even though we might try to keep it all CLR based, some of the things like unique constraints, like referential integrity, will be in the database. So, what I sometimes suggest to do is to have a separate solution, in terms of your development team, where you put all your business rules.

This includes both the SQL statements for defining your unique constraints and your referential integrity. Also put in that validation logic, your workflow that you’re going to be running server-side. If it’s AJAX controls and regular expressions that you’re going to be doing client-side in order to validate that data, absolutely make sure you have, from a development perspective, one place where you can go where you can see everything, because if you don’t do that [inaudible] can be running, and when things stop working, you won’t know how to debug it.

Ron: All right. Well, excellent answer. Udi, thank you so much.

I’ve included a direct link here for convenience (webservicebridge.zip).

In this sample, we have a service communicating over msmq, receiving a request message, and based on the value of the Id in that message, return either a success or fail result.

A regular web service makes use of that nServiceBus service in order to expose a synchronous API: “ErrorCodes Process(Request r);”

The implementation of the synchronous web service does some threading stuff to bridge the synchronous and asynchronous worlds.

And last, we have a regular web app which makes use of the synchronous web service.

____

I’ve also opened a discussion group for nServiceBus on Yahoo Groups, so you can find that here:

http://tech.groups.yahoo.com/group/nservicebus/

I’m going to try to take the information from the email exchanges I’ve been having and put them up so that the broader user base can take advantage of it. I won’t be putting up who sent me the email, or any identifying characteristics either of them or their employers, partners, etc.

Please send further questions about nServiceBus via the discussion group. Specific consultations can continue being sent directly to me – consult@UdiDahan.com.

Finally, if you have any ideas or suggestions for taking nServiceBus forward, please don’t hesitate to send them my way via the discussion group.

Thanks.

Ketan asks:

Hello Udi,

I am Ketan, working as Analyst Programmer in India. I want some information regarding SOA Architecture. I have visited several blogs and sites and I do have enough knowledge regarding technical terms of SOA. I have worked a lot in 3-tier mechanism a lot and now want to switch on SOA Architecture in Visual Studio 2005.

I read your blog post How to migrate to SOA and liked the contents and am interested in doing it. Can you please be more precise about how to migrate from 3-tier to SOA? Actually, I have read whole content of above link and you have explained enough. But, still I want you to keep me out from dark. You have described it functionally, but I want some technical description of this process. Please help me in this.

If you can provide me some example/application (in which SOA Architecture has been implemented), then it will be very helpful to me.

Thanks in advance. Waiting for your favorable reply.

Ketan

Download

Download via the Dr. Dobb’s site

Or download directly here.

Additional References

• Blog post on migrating from layers to services
• Podcast on “Does SOA mean the end of OO”?

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

The Setup

Just so that the example is in itself secure, we’ll assume that the password is one-way hashed before being stored. Also, given a reasonable network infrastructure our web servers will be isolated in the DMZ and will have to access some application server which, in turn, will communicate with the DB. There’s also a good chance for something like round-robin load-balancing between web servers, especially for things like user login.

Before diving into the meat of it, I wanted to preface with a few words. One of the commonalities I’ve found when people dismiss asynchrony is that they don’t consider a real deployment environment, or scaling up a solution to multiple servers, farms, or datacenters.

The Synchronous Solution

In the synchronous solution, each one of our web servers will be contacting the app server for each user login request. In other words, the load on the app server and, consequently, on the database server will be proportional to the number of logins. One property of this load is its data locality, or rather, the lack of it. Given that user U logged in, the DB won’t necessarily gain any performance benefits by loading all username/password data into memory for the same page as user U. Another property is that this data is very non-volatile – it doesn’t change that often.

I won’t go to far into the synchronous solution since its been analysed numerous times before. The bottom line is that the database is the bottleneck. You could use sharding solutions. Many of the large sites have numerous read-only databases for this kind of data, with one master for updates – replicating out to the read-only replicas. That’s great if you’re using a nice cheap database like mySql (of LAMP), not so nice if you’re running Oracle or MS Sql Server.

Regardless of what you’re doing in your data tier, you’re there. Wouldn’t it be nice to close the loop in the web servers? Even if you are using Apache, that’s going to be less iron, electricity, and cooling all around. That’s what the asynchronous solution is all about – capitalizing on the low cost of memory to save on other things.

The Asynchronous Solution

In the asynchronous solution, we cache username/hashed-password pairs in memory on our web servers, and authenticate against that. Let’s analyse how much memory that takes:

Usernames are usually 12 characters or less, but let’s take an average of 32 to be sure. Using Unicode we get to 64 bytes for the username. Hashed passwords can run between 256 and 512 bits depending on the algorithm, divide by 8 and you have 64 bytes. That’s about 128 bytes altogether. So we can safely cache 8 million of these with 1GB of memory per web server. If you’ve got a million users, first of all, good for you Second, that’s just 128 MB of memory – relatively nothing even for a cheap 2GB web server.

Also, consider the fact that when registering a new user we can check if such a username is already taken at the web server level. That doesn’t mean it won’t be checked again in the DB to account for concurrency issues, but that the load on the DB is further reduced. Other things to notice include no read-only replicas and no replication. Simple. Our web servers are the "replicas".

The Authentication Service

What makes it all work is the "Authentication Service" on the app server. This was always there in the synchronous solution. It is what used to field all the login requests from the web servers, and, of course, allowed them to register new users and all the regular stuff. The difference is that now it publishes a message when a new user is registered (or rather, is validated – all a part of the internal long-running workflow). It also allows subscribers to receive the list of all username/hashed-password pairs. It’s also quite likely that it would keep the same data in memory too.

The same message can be used to publish both single updates, and returning the full list when using NServiceBus. Let’s define the message:

And the message that the web server sends when it wants the full list:

And the code that the web server runs on startup looks like this (assuming constructor injection):

And the code that runs in the Authentication Service when the GetAllUsernamesMessage is received:

And the class on the web server that handles a UsernameInUseMessage when it arrives:

When the app server sends the full list, multiple objects of the type UsernameInUseMessage are sent in one physical message to that web server. However, the bus object that runs on the web server dispatches each of these logical messages one at a time to the message handler above.

So, when it comes time to actually authenticate a user, this the web page (or controller, if you’re doing MVC) would call:

When registering a new user, the web server would of course first check its cache, and then send a RegisterUserMessage that contained the username and the hashed password.

When the RegisterUserMessage arrives at the app server, a new long-running workflow is kicked off to handle the process:

That UsernameInUseMessage would eventually arrive at all the web servers subscribed.

Performance/Security Trade-Offs

When looking deeper into this workflow we realize that it could be implemented as two separate message handlers, and have the email address take the place of the workflow Id. The problem with this alternate, better performing solution has to do with security. By removing the dependence on the workflow Id, we’ve in essence stated that we’re willing to receive a UserValidatedMessage without having previously received the RegisterUserMessage.

Since the processing of the UserValidatedMessage is relatively expensive – writing to the DB and publishing messages to all web servers, a malicious user could perform a denial of service (DOS) attack without that many messages, thus flying under the radar of many detection systems. Spoofing a guid that would result in a valid workflow instance is much more difficult. Also, since workflow instances would probably be stored in some in-memory, replicated data grid the relative cost of a lookup would be quite small – small enough to avoid a DOS until a detection system picked it up.

Improved Bandwidth & Latency

The bottom line is that you’re getting much more out of your web tier this way, rather than hammering your data tier and having to scale it out much sooner. Also, notice that there is much less network traffic this way. Not such a big deal for usernames and passwords, but other scenarios built in the same way may need more data. Of course, the time it takes us to log a user in is much shorter as well since we don’t have to cross back and forth from the web server (in the DMZ) to the app server, to the db server.

The important thing to remember in this solution is doing pub/sub. NServiceBus merely provides a simple API for designing the system around pub/sub. And publishing is where you get the serious scalability. As you get more users, you’ll obviously need to get more web servers. The thing is that you probably won’t need more database servers just to handle logins. In this case, you also get lower latency per request since all work needed to be done can be done locally on the server that received the request.

ETags make it even better

For the more advanced crowd, I’ll wrap it up with the ETags. Since web servers do go down, and the cache will be cleared, what we can do is to write that cache to disk (probably in a background thread), and "tag" it with something that the server gave us along with the last UsernameInUseMessage we received. That way, when the web server comes back up, it can send that ETag along with its GetAllUsernamesMessage so that the app server will only send the changes that occurred since. This drives down network usage even more at the insignificant cost of some disk space on the web servers.

And in closing…

Even if you don’t have anything more than a single physical server today, and it acts as your web server and database server, this solution won’t slow things down. If anything, it’ll speed it up. Regardless, you’re much better prepared to scale out than before – no need to rip and replace your entire architecture just as you get 8 million Facebook users banging down your front door.

So, go check out NServiceBus and get the most out of your iron.

Jarrod asks:

Hi Udi,

I have some questions around versioning and SOA:

Over the years I’ve been fairly adamant about the practice of versioning interfaces should a method change be needed.

Hence, IDog and IDog2

Generally I would also say that a method addition would need a new interface as much as a change to an existing method or property (sometimes requiring completely deprecating the old interface).

With SOA being used more and contract first designs coming down the pipe…an addition of a method or operation to a contract in SOA does not mean its a breaking change.

So, do you continue to create a new interface and version the name within an SOA environment? Even if its just one method that is being added?

A service contract, in general…with just a single method in my opinion is a bad design. Sure, there are exceptions to that but I can just see changes made to the service contracts over the course of a few years with many 1-2 method interfaces.

Day 1 : 12 methods on interface IDog

6 months later : 1 new method, create IDog2 which implements IDog

15 months later : 2 new methods, create IDog3 which implements IDog2

Some can argue that if you’re having to add methods like this, the original design was flawed. That may be…or you could just be in a volatile business environment in which SOA must adapt.

So my main questions are:

1) Do you think its the best practice to continue to version interfaces for non-breaking method additions in an SOA environment in which you also have control of the consumers (internal consumers)?

2) Do you think its the best practice to continue to version interfaces for non-breaking method additions in an SOA environment in which you do not have control of the consumers (external consumers)?

3) If the answer to the above is yes, is a single method on a new interface acceptable?

4) If you know of a problem in an existing interface on a method and have control of the consumers – do you “fix” the method and redeploy to the consumers? Or do you deprecate the entire interface and begin anew?

I’m interested in seeing your responses

Jarrod

Download

Download via the Dr. Dobb’s site

Or download directly here

Additional References

• Podcast on Autonomous Services and Pub/Sub
• Blog post on “The Perils of WSDL first”

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

Suresh asks:

Hi Udi,

I’ve been reading about the coming “durable services” that will be available with the next version of WCF. I also have been listening to your podcasts and reading your blog posts about NServiceBus where you talk about long-running workflows. It sounds like both of these technologies are trying to solve the same problem.

Do durable services do away with long-running workflow? If so, does that mean we don’t need Workflow Foundation either? If not, what is the connection between them.

If you could shed some light on the matter that would be great.

Suresh

Download

Download via the Dr. Dobb’s site

Or download directly here

Additional References

• Blog post on Workflow Services in Orcas
• Blog post on Orcas Durable Services
• Blog post on .NET Framework 3.5 Beta1 is Live on the Web

Want more?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question to answer on the show.

Here are some choice tidbits:

“For any developer who architects using SOA principles, on the basis for using NServiceBus over some other methodology or some other so-called enterprise service bus:”

NServiceBus makes it difficult to work in ways that will hurt your scalability. Since the asynchronous messaging patterns are brought to the fore, developers will, by default, avoid the temporal coupling so prevalent in most Web Service implementations. Other methodologies make so many other options just as easy to use that developers can make mistakes that will hurt their scalability and availability and only find out about those mistakes in production .

Another thing NServiceBus does differently is to totally isolate all workflow code from all technologies. This makes it easy to unit-test workflow classes, making it possible to iterate quickly on the development of key business processes. These portable .NET POJOs give developers the flexibility to host their workflows in whatever runtime they want.

“Having noticed NServiceBus is built with MSMQ in mind or as an option, when asked why this choice of direction: ”

The core of NServiceBus is not dependent on MSMQ. The extensibility points of NServiceBus allow you to plug in your own communication transport, subscription storage, and workflow persister. I’ve already implemented a transport over MSMQ, and another over WCF’s NetTCP binding. Developers can use those as-is or write their own. Many of the SOA products currently out there are much more tied to HTTP, so this is something of a break from the common practice.

I chose to use MSMQ since it is one of the two main Microsoft communications technologies that enables parties to communicate in a disconnected fashion (SQL Server Service Broker is the other). MSMQ has a much more accessible API in that it is directly available as a part of the .NET Framework whereas Service Broker currently isn’t. I consider disconnected communications a critical part of any SOA infrastructure since the Tenet of Service Autonomy does not allow us to assume that the service with which we wish to communicate is currently available.

Is there anything you’d like to know about NServiceBus? Drop me a comment below.

Thanks.

I’ve also put in a bit of effort in setting up a bunch of configuration files allowing you to try the various transports for the example code. Please go through the Readme as it contains the detailed instructions. There are currently config files setting up non-WCF MSMQ, NetTCP, Basic HTTP, and WS Dual.

If you do go the MSMQ route, the example will run the long-running workflow code. The reason the example code won’t do that for the WCF cases is that I haven’t figured out yet the best way for a service to send a message back to itself, especially for the connected bindings. Any thoughts on this would be most appreciated.

Also, I’m open to hearing what directions you think the next version should go in. I’m currently thinking about including message transformation. Either that are doing a Multicast bus over a UDP transport.

This is a non-backwards-compatible update. In order to propertly integrate with the WCF philosophy I had to change the ITransport interface for Unicast transports. The meaning of this change is that transports are now expected to do their own threading and transaction management, while the bus object now joins the context that comes from the transport.

Download here.

My question is about distributed topology.

The EAI-hub-and-spoke model is all about the central server. It’s useful sometimes, but there are a lot of reasons why I’m not gung-ho on using a hub as the center of the integration universe.

The ESB distributed model puts code on the endpoints. That code solves some of the messaging problems that apps face, so that apps don’t have to face them. It also solves some of the messaging problems that enterprises face, so that enterprises don’t have to face them. (I need both).

Those problems include simple coding and deployment model, pub-sub routing, reliable transport, simple transformation, and orchestration. I wonder which of these you can do in your tool, and which you are planning to do.

I’m also interested in management. How do you insure that the endpoints are correctly configured? Do you have a central configuration store? How do you propagate changes from the center to the messaging endpoints?

And here’s my response:

The important parts of NServiceBus that are independent of the distributed topology are the API and the connection to long-running workflow. This code is indeed on the endpoint. However, if you wanted to you could easily connect to something like BizTalk and do whatever you wanted there. This general idea though is to support the ESB distributed model since there’s no such things as a centralized ESB.

In terms of the capabilities you’ve mentioned, I’ve seen developers pick up the coding model in a day or two. The deployment model is just a bunch of DLLs you deploy with each endpoint. Dependency Injection is supported by www.SpringFramework.net but you can replace that with something else easily as another implementation of the ObjectBuilder interfaces.

Currently pub/sub routing is supported over regular point-to-point transports in a transport agnostic way. You also have the ability to have subscriptions be persisted so that even if a server restarts (and clients don’t, and can’t know about that) all the subscriptions will be remembered.

The reliable transport that is currently supported is MSMQ, with the option of defining per-message type if you want durable messaging (using the [Recoverable] attribute).

In terms of orchestration you get a nice model for long-running workflow that gets kicked off by messages decorated with the [StartsWorkflow] attribute, and messages that implement the IWorkflowMessage interface get automatically routed to the persistent workflow instance. You have the ability to change the storage of workflow instances easily as well. Workflows are simple classes which are easily unit-testable in that they expose a “void Handle(T message);” method for every message type (T) that is involved in the workflow.

I haven’t done anything in terms of simple transformation yet but am currently looking for the right place in the message processing pipeline to put it. I also haven’t done anything yet in terms of management.

What is currently being done management-wise on the projects that use it are the commercial options for managing configuration files in distributed environments coupled with the regular ability to restart windows services and IIS applications. I haven’t seen anything lacking in that solution yet.

If you have any questions, please don’t hesitate to send them my way – NServiceBus@UdiDahan.com.

First of all, there were two major forces that drove me to write NServiceBus. First of all I wanted to formalize the way Service Layer classes were written when using asynchronous messaging (regardless of Web Services). And second I wanted to formalize a communications API which supported pub/sub so that I could freely move between transports – whether they inherently supported pub/sub or not (the fact that Indigo did not falls under this).

From there it was filling in the details. Until finally I made the step to formalize the way long-running workflow connects to asynchronous messaging. That’s the third pillar as far as I’m concerned about ESBs. Using MSMQ I do enable Shared Subscriptions like Sonic does.

I try to stay away from the vendor side of ESB definitions and just deal with what capabilities such a library should provide. As such, it is inherently distributed – running on each server/client.

1. In a webservice scenario, Is it the webservice which is the client?
2. Will a bus locate the WS or WS locate the bus?
3. How will the WS pass a message to the bus?
4. How will a WS subscribe to a bus?
5. Will it be possible to show an example project where you are using a WS and a bus and a WinForm/WebForm as the client?

1. The answer is a bit dependent on how you use web services today. If you don’t care about the client of your webservice (as in you have a public web service), then yes, the web service would be the client in my example. If you are using web services today to connect your win client to a back end server, then you would in essence be replacing the classic web service stack with NServiceBus, possibly using an implementation of ITransport which uses web services for transporting the messages.

2. The “bus” object which you use to communicate does not need to be “located”. Its just a regular object you use within your process on the same thread as your regular code. If the bus needs to communicate with a regular web service, you would use a transport that supports web services as stated above. In the configuration of such a transport object you would probably include the URI of the web service.

3. Sending a message is just creating an instance of a class which implements the IMessage interface and calling the “Send” method on the bus object.

4. You have to look at a web service as just some code that is running in a process hosted by IIS – therefore subscribing to message types is the same as in the example code. The important part to understand is what it means to subscribe to a message type. All it means is that when the publisher will call the “Publish” method on his end, a message will be sent to the endpoint your bus is listening on. When that message arrives, the bus will attempt to dispatch it to a message handler. If you don’t have a message handler which can handle that message type, nothing will happen.

5. I’ll get an example up soon. In a web client scenario, your ASP.NET application would be the client shown in the example code.

Please feel free to send me questions, either in the comments or to NServiceBus@UdiDahan.com. I’m more than happy to answer them.

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

And the question that this answers is:

Hi Udi,

We’ve been having some discussions about how to implement our latest project using SOA and this is what we came up with:

Every activity is a method, which is broken into a class ( Think separation of concerns ), so we get high reusability.
On top of those classes we have decided to put a WCF layer, so you can expose the method as a web method. If an activity needs data, then it will access a entity service via WCF. To make the activities useful for the business we put them in a class which we have called processes ( a process layer). A process contains one or more activities and is able to call other processes and activities aren’t allowed to call processes or other activities. On top of each process we have decided to put a WCF so the UI can access them.

So it’s pretty close to what you wrote about in the Microsoft Architecture Journal except that we don’t have direct call to the entity services, we wrap it up in an activity before the call, which is wrapped in a WCF-host. Much like the definitions in Ontology and Taxonomy of Services in a Service-Oriented Architecture

I would love to hear your comments and thoughts about this architecture.

With thanks, Ingo

Download via the Dr. Dobbs’ site.

Or download directly here.

Additional References:

• Ontology and Taxonomy of Services in a Service-Oriented Architecture
• Udi’s Architecture Journal article on Autonomous Services
  
• Podcast on how to structure .NET solutions and components
• Blog post covering a discussion on Entity Services

Want More?

Check out the “Ask Udi” archives.

Got a question?

Send Udi your question and have him answer it on the show: podcast@UdiDahan.com.

This update includes support for long-running workflows and includes persistent timer functionality. Workflow persistence is abstracted behind an IWorkflowPersister. The current drop includes an in-memory persister, but you could easily implement it over a database, or a distributed in-memory datagrid / space.

Other important details. To have a message kick off a workflow, just put the StartsWorkflow attribute on it. To define a message type as being involved in workflows, have it implement IWorkflowMessage instead of just IMessage. If you do these two things, the infrastructure will be able to generically dispatch messages to your workflow; you will not have to write any message handlers for your workflow, just the workflow class itself. This is done by implementing IWorkflow<T> for every message type received.

Persistent timers are activated from within your workflow like so:

this.reminder.ExpireIn(TimeSpan.FromSeconds(5), this, state);

As always, dependency injection is used – via my simple ObjectBuilder. The implementation provided delegates to Spring, but, once again, that can be easily substituted with whatever you want.

Download (509 KB) (sometimes problematic with IE, try FireFox before emailing me).

Finally, I’m leaning towards changing the name to NServiceBus. Anyone against, please leave a comment. Questions and comments are more than welcome.

Next step: implementing a WCF transport.

Download via the Dr. Dobb’s site.

Or download directly here.

And here’s the question that gets us started:

Hello there,

We are developing an application in .NET Smart Client application which connects to a WCF service and then to the data access layer. The issue we have here is on the type of data which can be passed between the client side and web service.

1. Can it be a dataset (No!), custom entity or XML or anything else ?

Which is the best one ?

2. Ofcourse , a dataset can’t be used coz it can’t be used in non-.NET environment?

3. If we go for custom-entity or XML how do we ensure the changes happen to the data during client-side actions ? For example, binding the XML or custom entity to a data grid can be done. But if user makes any changes to the same, how do we identify ?

4. If we use custom entities / XM L, the same can not be passed to the Data Access Application Block which invokes the data objects.

Note : All the above are based on assumption without using a translator in between any of the layers.

Please provide a better solution if you have come across any.

Additional References:

• Podcast on using DataSets with Web Services
• Blog post on tracking changes to objects on the client side
• Looking for more of the “Ask Udi” podcast?