Nice straw man – but it doesn’t fly.
Neither do oranges and orangutans.

.NET fully replaced all of COM and C++ as a developer API.
WCF does not do that with .NET.

Don’t you see parallels if you take your own argument and replace ‘WCF’ with C and ‘.NET’ with assembler?
Or ‘WCF’ with C++/object orientation and ‘.NET’ with C?
Or ‘WCF’ with COM and ‘.NET’ with C++?
Or ‘WCF’ with .NET and ‘.NET’ with COM?
We know how those arguments turned out!

First of all, I thank you for speaking up on this matter which impacts many developers and architects. I appreciate your position and would like to continue the conversation…

“Don’t give up on WCF yet, it’s going to be around in one name or another for a while!!”

COBOL’s still around too

“to get the real benefits of WCF you really need to change how you architect your application”

If you are suggesting that the architectural practice of finding the appropriate solution to the specific problem domain is made irrelevant by any technology – well, I’m afraid I strongly disagree.

“WCF was designed to provide solutions to all those typical problems”

Actually, I believe that WCF was created to replace ASMX web services, remoting, and enterprise services (aka COM+) – giving a single technological stack.

Looking forward to hearing your reply,

Udi

there’s nothing in that article that presents a problem. As Juval says and as WCF does, it solves the deadlock and any other concurrency issues you will get when not using WCF.

WCF was designed to provide solutions to all those typical problems developers run into when they start using multiple threads and windows forms. It’s not just about making calls to a remote client anymore. This is something else Juval clearly points out in his presentation. And that’s why he suggests it is “a better .Net”.

I’ve never had any deadlock or concurrency issues since using the iDesign techniques. Most of the problems were resolved without having to actually write any code, just the fact that .Net knows WCF is being used takes care of synchronization automatically for you.

If you find your still having trouble with forms, threads and synchronization is probably an application design issue that needs to be resolved rather than a WCF issue. Juvals 2nd edition of his Programming WCF book goes a lot further into answering these very same issues (as I’m pretty sure iDesign were flooded with emails about them!).

As I said in my previous post, to get the real benefits of WCF you really need to change how you architect your application. It just doesn’t work when you try to get WCF to do things how you “used” to do it. You need to embrace new technologies and use them how they were intended to be used.

I’m still amazed at how may developers are developing .Net applications that require transactions, concurrency control, synchronization and multiple threading, and yet they haven’t considered using WCF!

I’m also still amazed that Microsoft hasn’t spent more time educating the developer community on how to use their tools effectively. There are so many anti-Microsoft technology blogs, and only a few championing them. And yet the few championing them don’t have the same issues as the anti-Microsoft brigade

Without going to far off-topic, I think this is Microsofts biggest problem. They need to reach the masses rather than focus on the few when it comes to these kind of debates.

Don’t give up on WCF yet, it’s going to be around in one name or another for a while!!

I suggest you read Juval’s article on the myriad of ways you can deadlock yourself when following that guidance. I’ve linked to it here:

udidahan.weblogs.us/2008/04/11/wcf-smart-clients-and-deadlocks/

Lest we not forget, in the pursuit of our own productivity, that our users’ productivity comes first.

As everyone else that hears this for the first time does, I raised my hand and asked him to explain that again. Juval touches upon this again in his Architects Master Class when he talks about run-time processes allocation. This time I had two years of testing this theory behind me so I completely understand the benefits of what he is talking out.

The key to understanding the benefits is to understand the context that his statements are placed. And don’t forget that the context isn’t always a distributed system using Big SOA and Little SOA…sometime it’s a desktop application using “Mini” SOA, making use of WCF services hosted in-proc and still reaping the rewards of layers, boundaries, isolation that SOA gives you.

GadiM, you correctly highlighted three of the most important elements to the context in points 2, 4 and 5. Points 4 and 5 are clearly something in the (near and definite) future, whereas point 2 is something you can benefit from today.

Yes, it requires a change in how you would usually design or architect your application, but then so does introducing a new design pattern (How much work is involved in implementing MVC??!!). A little bit of extra work goes a long way, especially when you have to consider fault isolation, security isolation, time-line isolation, transactions, throughput, responsiveness (more services doing small steps), and not forgetting consistency…in WCF you get all of that in a single programming model, straight out of the box.

As a programmer, I don’t relish the thought of having to do any of that in my code, I would rather it was taken care of for me (and by people that are experts in security, transactions and threading). Whether you use the Microsoft Enterprise Library, WCF or write your own libraries. It all still needs to be done, so why not mitigate any implementation issues by using what you get for free in WCF.

“Trading performance for productivity” is always a benefit…unless you’re writing 3D computer game graphic code ;o)

1. Juval never removed ANY attribute on any service. What he removed where implementation lines that were irrelevant to the points he was trying to make.
2. Juval recommended that every cross-layer call is done on a service and not that every class is a service (the context is important).
3. Juval demoed 200 calls/sec using every feature WCF have, on his laptop (which is not a server), assuming your eye need 30 frames per second for normal view, it is enough for a watch (but probably not enough for device driver).
4. Juval did not say that you should actually use every class as a service today. He did say that it is where we are heading as an industry (again the time context is important).
5. Juval also said that if you have to speculate where would a platform replacing .NET look like, class as a service would be the direction, based on the historical tread of always trading performance for productivity. I am not under NDA so I can direct you to http://www.microsoft.com/soa/products/oslo.aspx to see if Juval was right.

Every one has the right to have its own opinion, and you don’t have to agree with Juval opinions, but you should at lease quote what he says and reflect what he did correctly before you disagree with him.

I have to say following the SOA tenant that SOA Services should be business use inclusive, doesn’t mean every single object needs to be WCF’ed. So I’m agreeing with you Udi, WCF should be used more in a business case SOA type perspective instead of a WCF everywhere approach.

…been there, done that, not doing it again.

The way Juval speaks, he makes it sound like this is what you should be doing today.

Even if it is a vision, it seems to remind many of the distributed object fiascos around a decade ago. The main thing that Juval didn’t get into was the architectural implications of working the way he describes. Flexibility is one desirable architectural property, but it’s not the only one, and needs to be balanced against others.

Ollie – that one of the main concepets behind nServiceBus.

Oran:

“most of the supposed benefits of in-process WCF can be better accomplished using dependency injection with decorators, or AOP”

Totally agreed.

I thought I remembered hearing Don Box suggest taking WCF in a similar direction (in-process services in the small), but the best I can find is his comment here http://pluralsight.com/blogs/dbox/archive/2004/10/13/2762.aspx#2765

As far as in-process performance, the NullTransport for WCF is interesting while we wait for Microsoft to find the time to implement it properly:
http://www.codeproject.com/KB/WCF/NullTransportForWCF.aspx
Roman says it’s about 2.5ms to 3ms faster than named pipes, I assume per call. His in-process WCF-workflow integration scenario is also quite interesting.

My personal opinion is that most of the supposed benefits of in-process WCF can be better accomplished using dependency injection with decorators, or AOP. You can do both of these with custom WCF programming, but it’s a lot more work. And since you can use existing DI and AOP tools to shim things into the service instances themselves, why bother getting WCF intimately involved?

People are aware of PI (Persistence Ignorance) why not go for CI – Communication Ignorance) as well. I don’t like the idea of attributing my domain model with a specific framework attributes.

Ollie

I think (hope) he just wants to make a provocative statement and doesn’t mean it in the literal sense

Arnon

I haven’t been able to get a copy of Juval’s presentation, but if I do I’ll post a link.

Like I said in the post, I have a hard time believing that this is what he advises his clients, so I too wonder about the intent of his message.

The thing is that Juval was suggesting to apply it in in-process calls between objects. I would say “in-thread” as well, but since that’s not possible in WCF, you might just find yourself in multi-threaded hell. Of course WCF synchronizes all access to service code, but what about if you have something like a customer object that needs to be used by two WCF objects? Are you going to be copying it all the time between the threads? That seems like a step-function in terms of complexity.

Thanks for backing me up.

I completely agree with you that this is going to kill performance. According to some experiments I did a few years back, even the fastest WCF call is approximately 100 times slower than an in-proc call (which is often so fast that you can’t really measure it).

But wait: WCF anywhere? Doesn’t that sound a lot like implementing an object hierarchy with DCOM, let alone .NET Remoting or CORBA? Then you’d be able to distribute your objects according to some arbitrary boundary you draw at deployment time…

We’ve already been there in the 90s, which led to Fowlers first law of distributed objects (”Don’t distribute your objects”) as well as the first SOA tenet (”Boundaries are explicit”). It may be fine in theory, but doesn’t work in practice.

So, I totally agree with you, Udi – I just wanted to provide some extra arguments against the “WCF everywhere” notion

All calls going through WCF go through 32 steps which can be independently configured. All client code interacts with is a proxy.

You can guess what happens when each and every call is encrypted at the caller and decrypted at the receiver.

The thing is that I’m not even sure that 5ms is the worst-case scenario.

Are the perf considerations here due to every method call being done as a message (a la Ruby) rather than an directly-addressed block of behavior?