The Four Tenets and Retirement

Rather than bash on the attribute-based approach of WCF, I think it's only fair to point out a few advantages:

- It's easy to understand
- It's not very intrusive related to whatever programming style you might prefer. I use TDD for most of my coding, and WCF really enables that technique, since I can typically just ignore those attributes and deal with the objects when I'm unit testing. If you were to take a more traditional object-oriented approach, you'd typically end up with a lot of base classes that you need to inherit from, and to ensure the flexibility that, say, TDD requires, you need to make a lot of your members virtual (with all the security implications of that), so I don't think that's a better option.

Currently, WSDL is still the goal of quite a major chunk of the service work being done today. Even when you don't really need it (like in pure WCF-to-WCF scenarios over, say, named pipes), the declarative and extensible metadata model actually works pretty well.

I totally agree with Aaron Skonnard that contract-first development is the correct approach when it comes to services. The question is then, how you model a service interface?

As far as I understand your question, you ask about how we would want to model a service interface in an imperative language, but I think that this is the wrong question to ask (if I may be so bold). A much more interesting question is how we would wish to model it at all (given no constraints)?

Today, contract-first basically gives you the option of writing the contract in WSDL, but I completely agree that this is an unpleasant experience, and is not likely to gain widespread acceptance.

The funny thing is that WSDL is actually a DSL, so it should be fairly easy to create tooling on top of it - yet I have yet to see good tools for this.

On the WCF stack, we should have a service contract modeling tool (maybe as a Visual Studio designer) which works on top of the WSDL (just as the XSD designer works on top of the XSD).

WCF already contains all the functionality of translating WSDL into a metadata model, so going from there to emitting code should be a breeze, but really, you don't even need to emit code at this point. WSDL IS code, so why not compile it right then and there if that's what you need? This could give you interfaces to implement in .NET without ever having to look at attributes or whatever it is that some people don't like :)

For extra points, include an XML-based annotation language that allows the modeller to specify how to map schemas into WCF types.

I really wished that decentralized publish/subscribe would poke it's head out in the MS world soon.

Have to agree on the samples

The biggest problems is people have no experience with SOA so they fall back on remote object tecniques but using an SOA tool like WCF.

Developers are lazy and will generall just continue what has been done . eg the samples show adding 2 numbers to illustrate a point . That sample is copied and methods start.

Then you see all the old RPC SearchBy methods .

Regarding TransferMoney , this has much scope like currency account type , authorised etc .

What we dont want but are seeing is TransferMoneyCheckToSavingAccount , TransferOverseas , etc

Regards,

Ben

I've responded to the "misconceptions" (I think of them as misunderstandings) you mentioned in your post:

http://www.innoq.com/blog/hw/2007/08/19/the_four_tenets_and_xml_messaging_with_wcf.html

Rereading my post I can think of some arguments against my proposal. However I'll love to respond to them ;-).

this was published last week, it has topics based on the four tenets

http://www.microsoft.com/downloads/details.aspx?FamilyID=cb2a8e49-bb3b-49b6-b296-a2dfbbe042d8&displaylang=en

One reason we see TransferMoneyCheckToSavingAccount and TransferOverseas instead of TransferMoney is because when we move into the service space we trade polymorphism and other OO-isms we have come to know and love for broader application reach and interoperability. In a word, I want my OO back, only this time WITH interopability.

I also agree that we should be doing contract first with a contract design surface instead of WSDL or C# first.