I am a bit confused on what exactly I am instantiating with the WCF ServiceHost when I have multiple endpoint contracts that I am adding to it.
The instantiation has included a typeof argument - which seems to be the contract and is so in everything I have read and done. However when I come across adding additional contracts - this is where my confusion about it is.
ServiceHost shost = new ServiceHost(typeof(MyService), NetTcpBinding, xyz);
So let's say I have several contracts - ProductService, BatchService, CustomerService these are endpoint contracts that each have an interface. Let's keep it simple there is an Add Method and a Get Method in each of these contracts.
I can then add these endpoints which are contracts to the ServiceHost ..
shost.Endpoint.Add(ProductService);
shost.Endpoint.Add(BatchService);
shost.Endpoint.Add(CustomerService);
This is my confusion if I create it with MyService, then does MyService need to incorporate the methods of all of my endpoint contracts or does this just pass in the first Endpoint Contract just to instantiate it and then all the additional ones are (forgive my lack of a better way of saying this) - additional services provided by the service that was instantiated with one of my endpoints ?
I have read on SO and looking here seems relevant and close - but does not give an explanation of the instantiation of the ServiceHost
Run WCF ServiceHost with multiple contracts
I mean what is the point of instantiating the thing ; and then adding endpoints if you have to place all of the endpoint methods into the host contract anyway where btw you can specify namespaces for the contract as well..- that just seems so un oop .. is the answer found at the link really the viable answer (it smells WET ~ W'peat Every Thing - AKA not DRY].
The ServiceHost can host one service - that is one service class (implementation class). But that single class can implement multiple WCF service contracts.
So if you have three service contracts (as interfaces IProductService, IBatchService, ICustomerService) and a single class MyServiceClass which implements all three of those interface contracts
public class MyServiceClass : IBatchService, ICustomerService, IProductService
then you can host this class in a ServiceHost and you can define endpoints for each of those three service contracts.
Related
I have a WCF service hosted in a console application. I have two ways to create WebServiceHost, either I create the instance of class implements service contract, and use that instance to create WebServiceHost, or tell WebServiceHost the type name of class implements service contract and let WebServiceHost controls everything.
In the first way, InstanceContextMode doesn't have any effects, it always equals to InstanceContextMode.Single, correct? InstanceContextMode only works when I do the other way: tell WebServiceHost the type name and let it controls creation of service contract implementation class. Is my understanding correct?
Yes, this is correct. MSDN says this explicitly - instancing works differently when you pass explicit object.
My project is a consumer for a 3rd party web service (old school web service vs. WCF service), and it has two versions, the "sandbox" (staging), and prod services. The APIs on these services are almost identical, and I am looking for a way to cleanly switch between the two versions, preferably without using conditional compilation.
I instinctively rushed off and extracted an interface from the client generated by Visual Studio's "Add web reference", i.e. AgentImport but that class is not partial, so I can't make it derive from the interface, or from any other superclass. I already have the creation of AgentImport instances nicely encapsulated in an abstract base for all my clients of AgentImport, but without using more risky compiler directives, how can I switch between v1 and v2 of AgentImport?
Some code:
using Clients.PrivateProperty.AgencyServicesApiService;
namespace Client.PrivateProperty
{
public abstract class PrivPropFacilityBase
{
protected static AgentImport Client;
protected PrivPropFacilityBase()
{
Client = new AgentImport();
Client.Timeout = 10000;
}
protected virtual AgentImport GetClient()
{
return new AgentImport();
}
}
}
I have tried adding service references instead of web references, as advised in comments below, to at least get access to partial classes, but when I add the first service reference, for the production service, and extract an interface from the auto-generated SOAP client, i.e. IAsapiClient, that interface references objects declared in other auto-generated classes, in the same namespace as the client, e.g. SecurityToken:
void UpdateUniqueAgentID(string PrivatePropertyAgentId, string AgentId, AgencyServicesApiService.SecurityToken Token);
If I add the second service reference, for the staging service, that second auto-generated SOAP client references objects in its own namespace, e.g. now it uses AgencyServicesApiSandbox.SecurityToken, so my compiler tells me that it doesn't implement the interface I extracted the first time. I am then left with the messy business of having to extract an new interface for each object that the main interface, IAsapiClient, references, so that this main interface only uses the extracted contracts, not actual class names.
In pursuing the above< I have reached the conclusion that my only feasible, and lowest risk, way forward is to use two client projects, one specifically for the production service, and one for the staging service. Then, at execution time, I only need to worry about dynamically choosing between two well known, i.e. not auto-generated, client objects.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
RESTful Workflow Service Endpoints in WF4 / WCF
I am trying to make Windows Workflow Services 4.0 work with a REST interface. I have a very simple workflow service called "Service1" with a receiveRequest and sendResponse activity.
By default WF Services autogenerate the classes and interfaces implemented, however i would like to force the WF Service to use my own REST enabled interface instead of some internal autogenerated interface.
The interface would be the following:
[ServiceContract]
public interface IService
{
[OperationContract]
[WebInvoke( UriTemplate = "/Data/{item}", Method = "GET" )]
String GetData( Int32 item );
}
However, i have difficulties configuring the XAML to work with this interface.
I would need a XAML configuration like this to specify that the Service contract name is my own contract:
<Receive x:Name="__ReferenceID0" CanCreateInstance="True" DisplayName="ReceiveRequest" sap:VirtualizedContainerService.HintSize="464,90" OperationName="GetData" ServiceContractName="w:IService">
However when i run this workflow service i get the following exception:
The contract name 'wfService.IService' could not be found in the list of contracts implemented by the service 'Service1'.
However, the service that gets created behind the scenes does not implement the IService interface and i would like to know how can i extend the service that gets instantiated by the workflow engine to implement my own interface (which i described above)?
Thanks
In WF4 you cannot declare ServiceContract in code and use it. Contract is declared in XAML and WorkflowServiceHost generates endpoint from declaration.
To enable REST for for your workflowservice you have few options:
Use HttpWorkflowHost from http://wf.codeplex.com/wikipage?title=WebAPIWorkflow. Limitation is that then you will have only REST.
Do something similar to this: http://msdn.microsoft.com/en-us/library/aa967564.aspx
Differences are: replace WorkflowFormatterBehavior instead of DataContractSerializerOperationBehavior, arguments are extracted from message contract instead of operation contract and keep in mind that you will not have client part of this example and you will have to format response according to protocol.
Trying to unit test my asp.net mvc 2 controllers, and having an issue mocking my wcf client code.
My interfaces for the wcf services dont' have open/close so I can do this:
IMyServiceClient client = new MyServiceClient();
And as a result it is harder to mock (moq) this class.
How can I work around this?
The reason IMyServiceClient doesn't have Open & Close methods is that MyServiceClient inherits from the System.ServiceModel.ClientBase<T> class. ClientBase<T> implements the ICommunicationObject interface which provides those methods. Mock this class by configuring it for mocking multiple interfaces (IMyServiceClient and ICommunicationObject).
I have set up some WCF services that I use to call from javascript to enable ajax calls such as retrieving data in JSON format.
All my services are configured in a web.config etc and I code in c#.
All my services inherit from a BaseService object which has some common properties that are share between all services, for example a logger object, configuration object etc.
My question is, how/where I can set up/assign values to these properties? ie. set up the base service logger property with an instant of a custom logger I created. Apologies if my question is vague but any help would be great.
Properties for Service implementation object cannot be set from client (any kind) because only contract is visible to client. Further, properties such as config and logger are anyway not meant to be part of contract but rather service implementation - so they must get set at server side automatically(i.e. by application infrastructure) for each service object. You have a couple of choices:
Use constructor (either that of BaseService or actual service class) to initialize these properties.
Use IoC/DependencyInjection container (for example, Unity, StructureMap)