tags:

views:

18

answers:

1

I'm pretty new to WCF and SOA, so I apologize if the question is poor.

The way I see it, if I could specify a contract's Name and Namespace in app.config, I could change the service that my client contracts use at runtime rather than compile time. Without the ability to specify Name and Namespace in app.config, my client contracts are limited to connecting to services with contracts with the same name and in the same namespace. Is this right?

So is there a way to choose Name and Namespace for a given contract in app.config? If not, why not?

+2  A: 

What you ask for doesn't make sense. The name and namespace identify the contract. The contract cannot change without changing the client. This is why service versioning is often performed by adding a new contract (with a new name/namespace combination), not by changing an existing contract.

You should think of a contract as being an unbreakable agreement between the client and service - you will always provide that set of operations.

You can, on the other hand, change the endpoint that your client references if you decide you'd like your client to use a different implementation of the contract. You can also change the binding by which the implementation is reached. But you must always maintain the same contract, unless you'd like to begin lying to your clients.

John Saunders
Hi John, thanks for your fast reply! Suppose I have a client that needs one or two operations from a service. I create a client version of the service's contract with only those operations. I use the service's contract's Namespace and Name. If I wanted to use a service with a different Name and/or Namespace, but nevertheless defined operations with the same signature as those I needed, I would be required to create another contract in my client which matched the first except for Name and Namespace. This makes sense for service contracts, but for client contracts?
Sam Pearson
@Sam: you **don't do** things like that. If the client only needs a couple of operations out of a larger contract, then it should simply not use the rest of them. If you have many clients that only need those operations, then perhaps you might want to create your own service that offers a contract with only those operations. Your service could then call the "real" service to implement them. BTW, what do you mean by "client contracts"?
John Saunders
I'm trying to follow the example at: http://www.codeproject.com/Articles/55690/WCF-Loose-coupling-of-WCF-Service-and-Data-Contrac.aspx. By client contract, I mean a contract that is used only in the `<client></client>` section in app.config, not in `<services></services>`. I think my confusion is arising from thinking that individual operations are like fine-grained services themselves, which they aren't (right?).
Sam Pearson
@Sam: no, the operations are part of the contract. They are not a contract in and of themselves. Don't take the fact that there are separate `<client/>` and `<service/>` sections as an invitation to play games like this.
John Saunders
@Sam: did you see this: "The code and scenarios do not necessarily represent best practices"? Stay away from this unless you have a specific need. If this is something you ran across in a Google search, then I suggest you ignore it until you have a lot more experience with SOA and can judge whether or not it's a good idea.
John Saunders
Understood. I believe now my confusion stems from a basic misunderstanding of what it means for a software architecture to be service-oriented. I'll do a lot more research. Thank you for your help!
Sam Pearson