I have a WCF web-service with four different clients , one of our clients wants more functionality , so we are adding , new OperationContract , which will use new DataContracts and some existing one
Existing Operation Contracts or DataContracts are not being modified
We will just be adding new OperationContracts and few new DataContracts
Would all of our clients have to update their service reference ? ( or clients who don't want the additional functionality of new methods, can go on using the service as they were)
if all of the clients would have to update their service reference , is there a way around it ? ( I want that only the clients who want to use the new operationContract , should update the service reference )
We have netTcp and basichttp bindings
WCF is very flexible when in comes to versioning as shown in this good MSDN article. If you change a service contract exposed automatically through a MEX endpoint, then all clients will have access to the new changes.
If you want to tightly control the contract exposed by a service then you could turn off the MEX endpoint and distribute the edited WSDL (and appropriate XSDs if not using singlefile) files to specific clients. Do not consider this a security measure since all you're doing is "obscuring" the fact that the service supports more operations that you are revealing.
If you do need to secure the different contracts then you will need to create separate services to expose the appropriate contracts to authorized clients.
Existing clients do not need to change. Under the hood the contract between clients and the server are soap messages according to the schema of specific operations. Since these operations have not changed the soap is the same so clients will work.
Related
Is it possible that we can expose few methods (OperationContract) of one contract ServiceContract) to one WCF binding and rest methods (OperationContract) of same contract (ServiceContract) to other binding ?
No. When you host your service you are free to define one or more endpoints for the service's operations in the configuration of the service. However, each of these operations will be exposed on all the defined endpoints. (The exception to this is that certain transport bindings do not support certain types of operations).
It sounds as if you should split your operation contracts into separate service contracts and then host two services.
I am just trying to get to grips with using WCF, and I am wandering if someone could tell me if I have the right idea with endpoints.
I have been working through the videos on msdn, and now I am wandering about the way to configure WCF Service. The scenario is if I have multiple IServices, e.g. such that I have an IThis and IThat, and the client needs the access both (note: they will be using net.tcp),
IThis handles database querying and,
IThat handles calculations independent of the database,
I assume that I have to define separate Endpoints for IThis and IThat, that are referenced in the client separately. Or would I create an overall IThisAndThat Service that gets referenced in the client and contains the functionality for both??
Or is are the other ways for developing and handling WCF Services with multiple IServices? While I'm asking can you define base address for tcp or only http?
~Thanks all, any help or pointers would be great.
I assume that I have to define
separate Endpoints for IThis and
IThat, that are referenced in the
client separately. Or would I create
an overall IThisAndThat Service that
gets referenced in the client and
contains the functionality for both??
You can do both:
you can create a separate service implementation class - one for IThis, another one for IThat
or you can create a single service implememtation class that implements both IThis and IThat
That choice is entirely up to you.
For every service implementation class that you have, you can define any number of endpoints you wish to have. So if you have an ThisService implementing IThis, you can define a HTTP and a TCP endpoint for that, and you also have a ThatService that implements IThat for which you define a TCP endpoint. That's totally up to you.
BUT: you can only define your endpoints for each service implementation class - if you have a ThisAndThatService implementing both service contracts, you cannot define 3 endpoints for IThis and two different ones for IThat - the endpoints you define are per service implementation class.
While I'm asking can you define base
address for tcp or only http?
Yes, absolutely - you can define a base address for each of the various addressing schemes (http, net.tcp, net.msmq, net.pipe and so forth).
Some basics:
Each service has one or more endpoints. The endpoints are specific to their relevant service, i.e. each endpoint can only belong to one service and cannot be shared between services.
An endpoint defines an entrypoint to the service - it includes an address, binding and contract that can be utilized by a client.
Different endpoints must have different addresses, and can have different bindings and contracts (i.e. they do not have to). Typically, different endpoints have different bindings - that is, transport protocol. They can have different contracts if particular clients are only supposed to have access to certain operations.
Finally, your service must implement all of the contracts that its various endpoints expose.
Here's a very concise and straightforward MSDN page which describes these concepts. http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/9f4391e9-8b9f-4181-a081-860d42b992a9/
There's a lot of information on WCF on the web, and there's a lot to learn. Best to look at some tutorials or guides which focus on what you are trying to do.
Consider I have a DataContract with 6 properties. one client needs first 3 properties and second client needs last 3 properties of the Data Contract. How to write the Data Contract in a service So that the Service sends the message with only Required properties?
The correct way to do this is creating separate service for each client. Each service will expose operation using its own data contract with only required properties. Both services will be just wrapper around your core logic working with whole data object. If the reason for sending only subset of properties is data security then creating two services is the only valid option.
If we consider this more detaily the problem here is service description. If you expose metadata / WSDL on your service it will always contain the whole data contract because you can't change it dynamically. If a client creates proxy from these metadata it will also receive whole contract.
You can avoid sending some properties in SOAP message if you configure your contract to not include properties with default values and do not set them in your service but I don't think it is a good solution.
I have 2 contracts (cA & cB) implemented by a single WCF service with 2 endpoints (epA & epB).
This is not for security purposes, but purely for reasons of clarity/organization, I'd like to only "see" ContractA's operations when I discover the service via endpointA; and likewise, only see ContractB's operations via endpointB.
I don't need to "protect" these operations per se. The scenario is such that any given client only needs one "side" of the service, never both (but, the operations themselves share resources, so it makes sense to have a single service rather than 2 services).
It seems that any given service basically gets 1 WSDL, ergo all operations are exposed to all endpoints. Is that the way it works, or is there a way to "shape" an endpoint by occluding operations not defined by the endpoints contract?
By default, you're right - one service implementation class gets one WSDL which contains all service methods (from all service contracts) that this service class implements.
There are no ways present (as far as I know) to "shape" the WSDL in any (easy) way - WCF does offer ways to get into the process of creating the WSDL (statically or dynamically), but those aren't for the faint of heart. It would be much easier for you to just split the implementation of the service contracts into two separate classes and then you'd have two separate services, separate WSDL's and all.
Marc is absolutelly right. I'm just adding why this happens in WCF. In WCF all metadata related functionality are based around service metadata behavior and mex endpoint. Both these features are defined on service level. So you can't take higher granuality (unless you write a lot of custom code) and specify metadata per endpoint.
WCF service (class) is directly mapped to wsdl:service element which exposes each contract as separate wsdl:port (in WCF known as endpoint). This is the main point in answering your question. If you don't want your second contract in that wsdl:service you can't implement it in the same class.
You have mentioned that your service contracts share resources. In that case your WCF service probably also contains business logic. That is a reason for your problems. The good design for implementing WCF services is to create them only as wrappers around separate business logic classes.
There is ABC (addres, binding, contract) = endpoint. I thought this information is enough to communicate with clients and vice versa. But what is metadata and mex?
The metadata that the mex endpoint exposes describes the service, the various operations, parameters the opertions require and the return types. In other words, the metadata exposes the contract. With this information the client can create a proxy to interact with the service. Clients use the mex endpoint to access the metadata.
Metadata inculdes the following:
For clients to create the proxy classes they need to know about the service contract, what operation contracts are available in the service contract, what parameters they take in, what are their data types, what data they will return etc.
Without these information clients will not be able create proxy classes.
Therefore we need to specify the service behaviours.