Clemens has a new post titled “Bad Habits to Give Up: Staring at Angle Brackets”. I agree, that is a bad habit to give up... you should keep doing it! :-) Seriously, though, that isn't what he meant.
Clemens perspective is that you should simply use Indigo's native programming model to capture your contract and let WSDL generation happen under the covers for the people who need it. Specifically, he says that:
Sharing this C# snippet here
[ServiceContract]
interface IHello
{
[OperationContract]
string SayHello(string name);
}
is a perfectly reasonable way to share contract between server and client, if you’ll be sticking to Indigo. A service can expose all the WS-MetadataExchange and XSD and WSDL you like so that other Web Service clients can bind to your service, but as long as you stay on the System.ServiceModel level and focus on writing a distributed systems solution instead of writing something that “does XML”, you won’t have to worry about all the goo that goes on in the basement.
The key phrase is “if you'll be sticking with Indigo”. While some people may not believe it, I'm a big fan of Indigo and if I could live in an Indigo-only world, I would do exactly what Clemens suggests. But if you work in a company that can't or won't commit itself to a single toolkit (and maybe even a single version of a single toolkit, depending on how versioning works), you probably can't take that path. Most large companies are in that situation. They have lots of different systems built lots of different ways. They may be able to do anything new using Indigo, but they need to integrate with existing systems that use other Web service kits (ASP.NET Web Services, Axis, etc). I find myself in a similar situation today: I'd like to be using my native C#, but my company is building in Java so I have to spend some time there too.
All of this comes back to reach, a topic I've been writing a lot about lately, including this post about “My 3 Web Service Stacks“. Clemens likes the toolkit-specific stack, where you get lots of rich, natural functionality but reach may be limited. If you focus on “writing a distribute system solution instead of writing something that 'does XML' “, you are very likely to do something that constrains your reach. That's okay if reach is not your goal. But if reach is your goal, this approach is likely to hurt you because you'll be leaving the details of the service contract that really matters - that is, WSDL/XSD/Policy - to the plumbing and just counting on it generating the right thing (and hopefully what that means won't change across toolkit versions).
The right thing, of course, is open to interpretation. If your plumbing generates a legal but overly complex schema that is hard for a customer to consume, you aren't making it easy for them to do business with you. Amazon and EBay wouldn't be making money hand over fist if they didn't put some effort into making it so that everyone can easily consume the services they provide. If you focus on your own toolkit and let it handle all the details of the contract for consumers using other toolkits, you run the risk of relegating those consumers to second class status. It's hard to think of a reason why you'd want to do that, other than it's easier for you. If your goal is to facilitate consumption of your service, then you should pay the price, suffer the pain, do whatever you have to to make sure that creating a client for your service is easy.
This is not really a new topic. Lot's of Web service developers would prefer to eschew WSDL's angle brackets in favor of code. When I worked at Microsoft, almost every internal WS spec I saw used C# to spec services, with the implicit assumption that we'd all be using not just ASMX, but a specific version of ASMX (because serialization behavior will change). This approach makes no sense to me. I think that “doing XML“ and thereby gaining reach is the aspect of Web services that makes the cost of reinventing our distributed platform yet again worthwhile. XML is not just an implementation detail, it is the implementation detail that actually makes this Web services thing work. If you don't care about XML and the reach it brings, why move to a new platform at all? Why not stick with one of the myriad of mature, well-known technologies that we already have at our fingertips?
So, all of that said, since Clemens shared explicit guidance on what he thought you should do, I'll do the same. I think you there are two things you have to do with Web services, regardless of toolkit, including Indigo:
1) Remember that WSDL/XSD/Policy is the contract, period. Any other view of your contract is just an illusion.
2) Write your logical contract explicitly, EITHER by writing WSDL down to the portType level, and letting an implementation stub in the binding, policy and endpoint information OR by writing code like Clemens does, but always knowing EXACTLY what's it's doing to your real contract.
Alternatively, I supposed you could just not care about your real contract. When that stops working for you, there is a tool that can help. ;-)
Posted
Feb 09 2005, 01:53 PM
by
tim-ewald