Hi have a service constructor for my WCF service. Which should ideally be initialized only once. But I see that the service constructor is being called every few minutes. Is there some timevalue or some other configuration setting which could limit the no. of calls to the constructor.
Creation of the WCF service class (and hence calling of the constructor) depends upon the services InstanceContextMode value. Depending upon its value (such as PerCall,PerSession, Single) service instances get created.
You can set the value to Single which would make the class act similar to a singleton.
You can do that by using a static constructor.
If the constructor needs to initialize non-static attributes, then maybe what you need is a singleton WCF service. WCF services can have different instantiation modes (PerCall, PerSession and Single)
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
Note that the single instantiation mode won't probably scale.
You can read more about service instance management here
Related
I have a WCF method which takes an argument that is a custom class, say,
void MyWCFMethod(MyCustomClass MethodArgument)
In the above, MyCustomClass has a number of constructor overloads. The service has a reference to the class but not the client. I want to allow the client to use the other overloads but the default constructor is the only one that seems to be allowed. Is there a way to do this?
You can certainly do this, but I think it is important to know why the Data Transfer Objects (DTOs) do not expose logic over the service reference.
The WSDL\XSD metadata that is used in order to generate the client proxy to access the WCF Service only describes the web service by the operations exposed and the datatypes exchanged.
Specifically, XSD only describes the structure of your DTOs and not the logic - that is why there is only the default constructor and public properties/fields available on the client proxy.
So the solution is to put all of your custom classes exchanged between the client and service in a separate shared library. This way both sides of the wire have access to the additional logic (like your parameterized constructors) that you could not obtain via WSDL\XSD.
I guess - no!
As I understand MyCustomClass is data contract and marked by [DataContract] attribute.
So WCF runtime will use DataContractSerializer (by default) to deserialize data from received message to the instance of object.
So where can DataContractSerializer get additional parameters for your specific constructors?
Instance of data contract must have public parameter-less constructor to be instantiated.
But maybe you can write own serializer (but keep in mind that DataContractSerializer cannot be inherited)... and provide additional data to constructor. But if you can get that information somewhere just do it in public parameter-less constructor of your data contract.
So I guess you are doing something wrong. Try to specify what is the goal to pass data in constructor in your case. Maybe your app can use some another solution.
Just want to confirm my understanding is correct. If I use Single instance mode for a service:
[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
and this service calls a class from another asssembly which has a static constructor, that constructor is only called the first time ther service is called? The constructor I am talking about sets up a fair number of AutoMapper maps, and I only want this overhead the first time the service is called.
Taking this further, If I have two different services, and they both us the shared class, am I correct that the static constructor is still only called once?
Best
Ray
There is no connection between InstanceContextMode and how many times static constructor is fired. Static constructor is called once per Application Domain. So if your services are hosted within one Application Domain then your constructor will be called once.
As far as I understand you use the contructor to register AutoMapper configuration... To me it is not a good approach. Assuming your services are hosted on IIS you would better create a Global.asax file and then run you mapping registration code in Application_Start method. Of cource you can wrap it in some static method first.
Hope it helps!
I would like to declare an interface in my Web Service layer and then have the caller create objects of this interface type via proxy and use them to call the service methods.
However, when I decorate the interface with DataContract attribute, I get an error saying this attribute can only be applied to class, struct and enum. I don't think that ServiceContract attribute makes sense, as the interface I am trying to expose is used only for data transfer purposes. I also noticed that when the interface was decorated with ServiceContract, it wasn't displayed in the proxy class created.
What is the best practice to go about this?
You cannot do that. "DataContract" interface cannot be exposed as part of metadata. Also even if you share the interface (in assembly) your clients will not be able to send their implementation back to your service because receiving side needs real type for deserialized instance.
The service contract is used on the interface, that is the name of the services. The data contract is used on the class, the data that you are sending over.
ServiceContract on the interface
OperationContract on the methods
DataContract on Class
DataMember on properties
See: http://msdn.microsoft.com/en-us/magazine/cc163647.aspx
I have a wcf service singleton type, and in the same application an ASP page that uses a service-specific function.
As I can get a reference to the service instance created, not to run twice the manufacturer's service?
My service is published on IIS
I'm guessing you are saying that you have a service that is supposed to be a singleton and because you're in the same AppDomain you can simply create an instance as well.
If you own the service code you can make it a singleton using the Singleton Pattern (there are a number of ways to do that in .NET and Jon Skeet has a list of them here).
Then you need to deal with how does WCF get hold of the instance? In that case there are two options:
Use a ServiceHostFactory and hand the instance to the ServiceHost you create
Implement IInstanceProvider and plumb that in
If you don't control the service class then there is nothing you can do to prevent people creating instances but you can wrap the class in your own singleton and stipulate access must only be via the singleton so it is less likely that someone will create a second instance
I am hosting a service within a Windows Service.
The following snippet instantiates the ServiceHost object:
Host = new ServiceHost(typeof(Services.DocumentInfoService));
The DocumentInfoService class implements a contract interface that has methods that invoke business objects requiring initialization (actually a connection string). Ideally, I'd like the hosting process to get the connection string from the config file and pass it to a constructor for my service object, DocumentInfoService, which would hold onto it and use it to pass to business objects as needed.
However, the ServiceHost constructor takes a System.Type object -- so instances of DocumentInfoService are created via the default constructor. I did note that there is another constructor method for ServiceHost that takes an object instance -- but the docs indicate that is for use with singletons.
Is there a way for me to get to my object after it is constructed so that I can pass it some initialization data?
ServiceHost will create the service instances based on the binding and behaviors configured for the endpoint. There's no particular point in time, where you can rely there is a service instance. Hence, ServiceHost does not expose the service instances.
What you could do is add code to your service object constructor to read the relevant configuration values itself through the ConfigurationManager class.
Of course, if you don't keep your configuration in the app.config, that won't work for you. Alternative approach would be to have a well-known singleton object that the service instances access when created to get the necessary configuration.
And there's also the option of creating your own ServiceHost or your own ServiceHostFactory to control the service instantiation explicitly. This would give you acess to the new service instances at the moment of creation. I would stay away from that option though. It's not worth the effort for your scenario.
Implement your own ServiceHost. See also http://hyperthink.net/blog/servicehostfactory-vs-servicehostfactorybase/