WCF Services—Service Design
|Visual C# Tutorials|
|.NET Framework Tutorials|
|© 2007 Chris Peiris, Dennis Mulder|
WCF provides the complete decoupling at design time of the service from the actual ABCs of the service implementation. Why? This provides a greater level of flexibility in both choosing the implementation model today (which consists of both the service and the ABCs) and providing the greatest amount of flexibility and extensibility for supporting varied transports available today and in the future. In other words, you can write and maintain a single instance of your service code without regard for what the physical deployment model is.
Now, in the real world, you still need to consider what the service provides and what the overall performance is as it relates to marshaling objects across service boundaries and ultimately coupling physical nodes separated by a LAN, WAN, or the Internet. So, as good solution architects, you must never forget the "Eight Fallacies of Distributed Computing" by Peter Deutsch; see
http://today.java.net/jag/Fallacies.html for more information.
In the ideal implementation, the service providers and service consumers will spend a significant amount of time collaborating from a business perspective. During that collaboration process, a service model will evolve to properly address many aspects of what the service contract will look like, including elements such as the following:
- Other "ilities" of architecture
To be clear, WCF doesn’t address these aspects directly; that’s up to the solution architect. WCF provides the base framework for implementing service contracts, in conjunction with the rest of the ABCs for a solid foundation of any SOA implementation.