10 Things I Hate About Indigo

Blog link of the week 32

I have to say that I really don't understand all of this negativity surrounding WCF and what it is providing to those of us who are building web services today. Maybe I'm simply naive to the underlying complexity that "oo semantics" introduces but I am starting to feel as though all of these issues have more to do with underlying design strategies than the technology that is implementing them.

You state above that your domain model is being corrupted by things like svcutil and attribute based programming. I would assume that this has something to do with the fact that there is too much code being masked from you. Don't you have the option to not use those attributes in most cases. Also isn't your domain model still preserved within the components you design and the methods for invoking their interfaces are something outside of that domain model all together? You also seem to be very concerned about over-configuration and rpc stylings creating tight couplings but aren't there features within WCF like multiple end-point definition and data/message contract versioing that make this platform more agile than anything before it? Doesn't that actually give us a looser coupling in a way?

So I have read much of the materials available at this time (Pallmann's book Programming Indigo for example) and I have followed all of these blogs between the Microsoft Indigo/Connected Systems Group Team and yourself. I really only put much credence in one of your points. The point you make about poor design direction and over-simplification of the examples is without a doubt the biggest gap in my mind to date.

I think there needs to be a major shift within Microsoft to help guide those that intend to use these technologies. The tenants of service orientation are rarely reinforced in the examples you see today and these "Morts" that you reference in your other blogs are going to spend much of their time abusing these technologies and not showcasing them.

I personally have mostly positive things to say about WCF/Indigo at this point. I build first generation web services today and I am literally hand cuffed by versioning issues, security issues, and hideous lack of boundary definition in my service libraries (ok nothing in the WCF release is going to fix the last one). I do expect WCF/Indigo to make my world as an application architect easier almost immediatley. By the way I'm not on Microsofts payroll I'm just well read on the subject and I have just about the opposite opinion of yours .... I'm just not convinced otherwise by your recent blog entries.

Thanks for taking the time to explain your concerns to me.

1. It sounds like a fair part of your reaction to Indigo is a reaction to the samples and David's book. In Beta1, with one book and a smattering of samples, we can only target a subset of our scenarios. It sounds like our initial efforts didn't speak to you. Hopefully, as more books and samples come out, some of them will be more to your taste, and you will be happier.

2. Indigo does have a simple message programming model for the client at the "upper-level". The client calls a method that sends a message and returns. The message is delivered to a method implemented at the service. If the contract involves return messages, the service can send them back to the client in a similar way.

3. Indigo does have a simple message programming model for the service that lets you respond to messages as events and send messages back to the client which are caught and responded to as events.

4,5. Are you unhappy here because you don't realize that Indigo supports simple messaging (your comments 2) and 3) seem to indicate that)? Are you unhappy because Indigo supports RPC as well as messaging? Are you unhappy because our examples and David's book lead with RPC? We can fix the first problem by exploring the details. We don't view the second issue as a problem at all: there are scenarios for RPC as well as messaging, and we find that people are really attracted to the idea of training their people in a single API that can be used to implement all the common distributed application patterns. We have worked hard to make the differences obvious and localized: if you understand how to process a message under a transaction, or how to do authorization, or how to use our instancing model, those things will work the same regardless of whether you’re doing messaging or RPC. If you’re unhappy with the focus of the first book and the examples, well, as I said, I hope people eventually talk about parts of the system in ways that speak to you better.

6. Again, you realize that you can do message-oriented programming at the upper layer, right?

7. As Tom says, most of the attributes in Indigo are shortcuts for imperative things you can do via APIs. Most people like the convenience of attributes, but we built the system so that people who don't like attributes don't have to use them. The one exception in V1 is contracts. Attributes are a convenient way to associate metadata contracts definitions with code that can be used to work with those contracts. Once our designers come online, you won't need to work with attributes. Once we have a richer modeling infrastructure, perhaps we'll have better ways than attributes to associate metadata with code. For now, they seem to us like the bets way to proceed.

8. Our config story is not like MTS’s config story. You cannot change things the code depends on for correctness from config. If the developer cares about the semantics of the transport/protocol stack (must have transacted queue, must have session, etc), they can assert these dependencies from their code. By default, we believe that the deployer is the one who should control the transport and protocol mechanisms at an endpoint -- HTTP or TCP, transport or message security, etc. Those are typically managed from config (though the developer can choose to ignore config and do what they want). Given this summary, what part of the config story do you disagree with?

9. Well, svcutil doesn't impose distributed object/RPC semantics. If you have a contract that has all [IN] and [OUT], then svcutil generates signatures used to send messages and process them like events. It's only if you have [IN/OUT] semantics in your contract that you will get RPC (which is what [IN/OUT] is about). If you dislike having a typed proxy generated for you that corresponds to the WSDL you want to use, then you can create the proxy code types yourself: you don't have to use svcUtil at all.

10. Of course I can't say anything in response to your assertion that we haven't thought through our architecture.

I don't mean to be rude or out of order, but if that is your viewpoint why do you insist on using Indigo and .Net? I mean, the folks at Microsoft have a certain way of looking at distributed computing and they've built Indigo in that vein. You want free-form, decoupled messaging? You can build it in PHP/Perl/Python very easily. For my company (http://vuniq.co.il) we looked at .Net and Java and both of them were overkill. Messaging is actually simple when you do it in a stateless, decoupled manner, and that's also the way it should look to the programmer.

Anyway, just my $0.02.

WCF rules my world.

I understand your statement about the domain model infection. Still, ask yourself if your domain entities should really double as datacontracts.

Certainly not for a rich domain model, because entities would need to fulfill both the data and operations contracts. As for an anemic domain model, what do you make of aggregates and lazy loading - those are operations hidden behind properties. And certainly you aren't planning on exposing repositories as operation contracts, that would be extremely silly.

So my answer to you is, leave your domain model intact, keep it in its own assembly. Your data and operations contracts should reside within the Application layer, not the domain layer, the same way your UI should not be directly coupled with your domain layer.

You may also prefer to step-up the architecture to 5 layers and have a service layer between your domain and application layers. In this case the client side has Interface and Application layers, then a big bold separation (in reality, the network sits here), then the server side has Service and Domain layers. Both client and server also have an Infrastructure layer - the infamous boilerplate.

What Eric Evans and Martin Fowler write are not meant as gospel, just inspiration. Adapt so you can leverage technology.