This question comes from the new approaches being suggested when designing services with WCF and even ASMX 2. The approach is one that uses interfaces (or abstract classes) to focus on the method signatures and avoid diving directly into implementation when desiging services. This looks like a half-way contract first approach that is meant to help developers focus on what makes a service reusable (strong typing, message orientation, explicit method naming, etc...).
Ok now my question is does this then take the concept of interface inheritance and cloudy it some. I personally favor the idea but I have a hard time convincing the OO guys that using an interface to encourage contract based service oriented design is worth the effort. In fact many OO guys think it makes things more confusing. If I in fact do not intend to implement the interface in multiple service end points is it too confusing to build services using this abstraction
The only other benefits I could come up with is how the interface in fact does get reimplemented by the proxy but that starts to sound a lot more like RPC style service development and less like message oriented service development which of course is a goal if I want to ensure reuse.
I have some more thoughts on this but I hope this just triggers some dialogue on the topic. I look forward to everyone's feedback!
Are interfaces for behavioral overloading only?
Demonite
There are two questions here
1. Is contract-first important - I think it is. As long as you don't expect it to be The Contract (making the contract The Contract is a waterfallish thinking IMO). Having a contract set-up early in the development facilitates parallel development and collaboration.
2. Are interfaces the way to describe the contract - as I mentioned in the pervious post here, I think using interfaces is not best way to go, because of its OO roots (which fosters OO thinking). I tend to agree with you that other tools are needed.
There are tools in the non-MS world e.g. http://www.capeclear.com/products/studio.shtml
I don't think XSD is user friendly enough. DSLs (whether explicit MS DSLs or just dedicated designers) are the way to go. I would expect tools to allow to also enforce rules on the designers working on contracts e.g. credit card data must not be sent as clear text, or, the more low-level don't allow using AnyAttribute wildcards etc. ( www.weblayers.com claim they have that - but I only found their site a couple of days ago so I don't know if they live up to their claims)
Arnon
Luuk
I think everyone understands the question, unfortunately I don't think there is a good answer here. We are obviously overloading the concept of an interface which has a well defined value in an OO design. The question of whether or not it makes sense to use an interface in service design comes down to a question of how valuable is contract first. I would argue that the value varies based on how knowledgeable you are of the pitfalls of designing for service-oriented reuse.
So in the end if I was thinking of introducing interfaces as a standard governance item with a service-oriented architecture I would need to be able to articulate the benefit of overloading the concept of an interface and potentially muddying the waters a bit when it comes to how and when I should be using it. In my opinion that is very difficult considering the challenge implicit in measuring the value proposition of contract-first service development.
I think the only way to do this correctly is with tools (which is what I think Siva is saying too). This is why I've started to get really excited reading the progress of Ed Bakker and Christian Weyer with a DSL that can govern this through tools and templates (see Ed Bakker's blog for more info on this). No need to create additional confusion through overusing an already established programming construct. I just really need a tool that can facilitate the creation of all the elements needed in my WSDL.
Agreed
vutkuri
<note>I am not usre I fully understood what you said so I might not make sense</note>
My experience with developers shows that using traditional (e.g C#) interfaces to design service contracts encourage RPC thinking of the parties involved and thus requires more attention by the architect to make sure the contracts stay message oriented.
Things get a little better when interface==message (i.e. don't plan a proxy where method==message but rather plan the parameters of each message as an interface) - This approach can save time when the teams go from planning to implementation where the interface agreed upon can be used by the edge and the service agents directly
Arnon
venky0425
The reason for confustion, I think, is that there are no formal tools or mechanism avaiable to design service contracts/end points up front. Since interface (which is a language construct) is the closest, people use it for contract-first, as you mentioned. Interfaces are used in real sense when it comes to implementation of such services. Ideally, XSD (used in WSDL) is the tool/language to do contract-first; from XSD, derive the service implementation.
Hope I got your question right.
-Siva
Vovka
Ok, if I understand you correctly the only advantage to this is an agreed upon interface that can be used by the service agents directly. This would be instead of a more traditional approach where you use the implemented method (potentially just stubbed out initially) to surface WSDL that a consumer can then build a proxy from.
I think I'm still struggling with whether or not this is a superfluous step in delivering services that adhere to the 4 tenets of service-orientation. That being said, it seems to be used everywhere today in the samples and technology stacks for building services. Why is that