We are developing a WCF service for internal company use. The entities (data contracts) are in a separate assembly and are referenced by both the service and applications that consume the service.
Is there any need to implement the IExtensibleDataObject interface?
No. IExtensibleDataObject (IEDO) is used if you expect your contract to receive (e.g., in a service call) more data than is listed in the data members. If you have the same assembly on both client and service this will not be the case.
For a more detailed description of the scenarios where IEDO is useful, check the post at http://blogs.msdn.com/b/carlosfigueira/archive/2011/09/27/wcf-extensibility-other-serialization-extensions.aspx.
Related
So is it that you shouldn't or can't use Interfaces in methods you are exposing or in the DTOs you are exposing to the client in a WCF service? Because if I have this for example:
public class MyCustomDTO
{
public ITransaction Transaction { get; set; }
}
or
IPaymentRequest SendTransaction(PreAuthorizeRequest request);
I notice that when I try to create integration tests to prove that the wsdl can be used and make successful calls, my ITransaction and IPaymentRequest are serialized and exposed through the service client as "object" probably because it doesn't know what kind of object to expose in the contract right?
so is it you can't create methods or DTOs with Interfaces in them as part of the contract you are exposing to the outside world that consumes your WCF service?
If you are using WCF to connect two .NET instances and you share your contracts as a common contract assembly between the two instead of using the auto-generated client from the wsdl, then it works. However, WCF is about interoperability and you may want to add a non-.NET client down the road so you should only use actual types so your service will work well with all the other languages out there.
I currently have several C# service implementation classes, each of which implements several service contract interfaces. Each service implementation class is at at a separate address, but all of its service contract interfaces are at the same address.
A client that wants to use interfaces from several services currently needs to know about several addresses.
I am wondering if it is possible to have several implementation classes share an address. For instance, currently, a client might connect to Browse.svc, Data.svc, Report.svc etc. Could I reconfigure so that the client only needs to go to Service.svc?
It seems to me that the SOAP Action provides a means for WCF to tell to which service implementation class it should direct the request, so this might be possible.
I really don't want to slam all my implementation into one big service class.
The following Microsoft article talks about this sort of thing, but doesn't seem to address the issue of multiple service implementation classes.
http://msdn.microsoft.com/en-us/library/aa395210.aspx
If you want one service, that can respond to multiple service requests. have a look at http://davybrion.github.com/Agatha/
It's an implementation of the request/response pattern for WCF.
I'm looking for a web service wrapper to convert my classes to web services. each class to a specific service and the type of instance management is "percall". are there any tools? Or are there any simple ways for this conversion?
for example this tool can add "service contract" attribute to classes and "operation contract" to public methods and also "data contract" to all inputs and output datas of public methods.
AFAIK that does not exist.
Web Services, with ASMX or WCF, are specific beasts. You cannot just take any class and make it a service. You need to define Data Contracts, Service Contract, an Operation Contract per method, etc.
Check out "Getting started with WCF" at http://msdn.microsoft.com/en-us/library/ms734712.aspx.
Good luck!
I wrote a couple of simple web methods (as a part of WCF service) that use a couple of (more complex) classes as input/returned parameters. Each web method attributed by [OperationContract], each data class attributed by [DataContract], each data field in the classes attributed by [DataMethod].
On the client side I can call these web methods by adding Service Reference.
All things are fine, but when I create an instance of some of the data classes above on client side, their constructors don't run.
Because it's a little complicate to initialize each instance, every time, I thought there is some way to initialize instances on client side by their own constructors.
Thanks in advance!
Ilan.
Methods exposed on data contracts (including constructors) in your service are only for service applications. Adding service reference will recreated only data structure of your data contract classes because service description is not able to describe logic and logic cannot be serialized.
All classes created with service reference are partial. You can create your own partial class and add your own custom constructors or you can share the assembly with data contracts between your service and client (but it will share all logic added to your data contract classes which is most often what you don't want). Sharing assembly will tightly couple your client and service.
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.