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)
Related
I'ld like to perform integration on stateless service in service fabric.Please help me on this. I have created the stateless service like c# web api.
In order to perform integration tests on your Reliable Service there is a number of dependencies you need to mock and take care of. You will not be able to test all situations or behavior of your service this way, the way the FabricRuntime hosts and runs services is difficult to replicate (without writing your own FabricRuntime equivalency). It is also worth noting that there is no way to run FabricRuntime without a cluster (including local development cluster).
You also need to consider how advanced your integration tests should be. For instance, does your service call out to other service (including actors) within the same cluster using fabric transport (the default communication model) that you want to include in your integration test? Do you need to ensure that state is persisted across multiple activations of the same service partition?
First you need to get rid of all hard dependencies to FabricRuntime (to things with dependencies to it) and also static support classes in your code:
Service/Actor proxy
Don't use the static ServiceProxy.Create<..)(..)> when calling other services, instead make sure your Service accepts an instance of IServiceProxyFactory in the constructor and use that instance to create proxies to services your service calls. Same goes for ActorProxy.Create<..>(..), replace this with an instance of IActorProxyFactory. In your program.cs where the service is constructed, give the service new ServiceProxyFactory() and new ActorProxyFactory(). That's the easy part, now you need to mock those so that your integration tests can actually create some form of proxy for downstream services. You will also need to create some form of container (like a mock FabricRuntime) that holds instances of called services and actors. It also gets tricky if you wan't to test that the RunAsync method of your service performs some function. Beware of creating this static though if you want to run it in a test runner,
you don't want different tests to get mixed up in the same container.
Service context
You need to mock your StatefulServiceContext well and how your Service is created. Your Service constructors need to accept an instance of StatefulServiceContext to pass along to the base class, so you are free to supply your own mocked instances of context there when you create the service.
public StatefulService(StatefulServiceContext serviceContext)
: base(serviceContext) {}
Service settings and activation context
You also need to see if your service implementation tries to read ICodePackageActivationContext or any of the settings from the Service manifest (like shown in this SO answer Where do you set and access run-time configuration parameters per environment for service fabric?). In that case you need to replace it with your own mockable version and you need to inject that in the constructor as well. What you find in most samples is a call to the service context, like this:
this.Context.CodePackageActivationContext.GetConfigurationPackageObject("Config");
If you do it this way in your service then you need make sure you have a mock of StatefulServiceContext as well and how your Service is created. When you register your service with the runtime in Program.Main() then you get and instance of StatefulServiceContext in the register call:
ServiceRuntime.RegisterServiceAsync("ServiceType",
context => new Service(context)).GetAwaiter().GetResult();
State
In order to mock state and get it to behave similar to what it will when running in a real cluster you need to mock the underlying handler for reliable state: IReliableStateManagerReplica and you need to add an overloaded constructor to your services that accepts an instance of that and sends it to the base:
public StatefulService(StatefulServiceContext serviceContext, IReliableStateManagerReplica reliableStateManagerReplica)
: base(serviceContext, reliableStateManagerReplica) {}
For actors its IActorStateProvider you need to mock if you want to handle state in your integration tests.
Summary
Depending on how advanced you want your integration tests to be and how close to the real execution model you want it to be, you may end up having to mock and replace a large number of classes/interfaces. The Web reference application sample
https://github.com/Azure-Samples/service-fabric-dotnet-web-reference-app has some implementation of Mocks for required classes, also https://github.com/loekd/ServiceFabric.Mocks contains Mocks for testing, although you might need to alter the code if you really want to run integration tests and not just unit tests.
There is no difference on your integration tests on stateless web api with a regular api.
Is there a way to get the binding that a WCF service is using from the object instance of the service class itself?
I'm currently debugging a WCF service and have changed the client bindings and want to see if they are the one's that are being applied to the proxy class that represents the service interface.
As an aside the proxy class is being created using the ChannelFactory<IMyWCFService>.CreateChannel() method. However as this is a MVC web application and the method call is done via Dependency Injection. So the proxy object is injected into my code.
So just to be clear at the point in the code where I am using the proxy object I don't have access to original ChannelFactory. I know the binding that the ChannelFactory is using as it is set whilst configuring the dependency injection container within the Global.asax.cs class. However as we are using dependency injection there is no guarantee that the ChannelFactory or indeed binding defined in the Global.asax.cs is the one being used to create the proxy object as it might have been changed by some other code. The issue I am having is we are changing explicitly setting values on the binding used in the Global.asax.cs class but this settings aren't taking affect which makes suspicous that another binding is being used.
You can get binding from Endpoint object of service:
var service = new Service1Client();
Binding binding = service.Endpoint.Binding;
Console.WriteLine(binding);
I'm going to be creating a service that needs to make a call to a hosted WCF service halfway around the world. This isn't that big of a deal since the number of transactions that will be made is relatively low. However, I need to pass in an instance of a class that will possibly be defined in the WCF to the necessary WCF function.
So my question is, will that instance of the class exist on my server? Or will I be contacting the host server every time I attempt to set a variable in the object?
EXAMPLE:`
public class Dog
{
public string noise;
public int numLegs;
}
public class doSomething
{
public string makeNoise(Dog x)
{
return x.noise;
}
}
`
All of those are defined in the WCF. So when I create an instance of class Dog locally, will that instance exist on my side or the server hosting the WCF service? If I'm setting 1000 instances of Dog, the latency will definitely build up. Whereas if I DON'T have to contact the server every time I make a change to my instance of Dog, then the only time I have to worry about latency is when I pass it into doSomething.makeNoise.
The host creates a new instance of the service class for each request, if you're using the default per-call instantiation method (which is the recommended way).
So either this is the IIS server which hosting your WCF service that creates an instance of your service class, or it is the ServiceHost instance that you've created inside your own self-hosting setup (a console app, a Windows service etc.).
The service class instance is used to handle your request - execute the appropriate method on the service class, send back any results - and then it's disposed again.
There's also the per-session mode in which case (assuming the binding you've chosen support sessions) your first call will create a service-class instance, and then your subsequent calls will go to the same, already created instance (until timeouts come into play etc.).
And there's also the singleton mode, where you have a single instance of the service class that handles all requests - this is however rather tricky to get right in terms of programming, and "challenged" in terms of scalability and performance
You will need to host your WCF service on a public available server (for example IIS). Successful hosting will provide you with a link for the svc file. Clicking on that will give you a link ending in singleWsdl. You need to copy that link. On your client side, the one that requires a reference to the WCF, you will need to Add Service Reference and pass that link. This will generate proxy code with Client objects that you can use to access your WCF ServiceOperation methods.
At a minimum you should have three projects. A website project to host the actual site. A WCF project to host your services. And finally a shared project, which should contain the classes you are concerned with (the models).
Both the website and wcf projects should reference the shared project, this way they both know how the models look.
The wcf project should return serialzed models as json objects, which I usually do by referencing Newtonsoft.Json.
Your website project should expect this json, and deserialize them, also using Newtonsoft.Json. This is why your class (model) should exist in the shared project, so you can use the same class on both sides of your service call.
Scenario:
I am consuming a web service in my class library project and it generates a binding name and end point in app.config. If I reference the class library in my UI project, I also have to include the same configuration in web.config. My problem is I don't want to include this configuration in web.config because of the dependency. I want to use assembly as it own with out any dependency.
My solution approach:
When I create the instance of proxy class in the class library project it shows me constructor to pass binding and endpoint.
Example
wsProxy proxyClass = new wsProxy(System.ServiceModel.Channels.Binding binding, System.ServiceModel.Endpoint endpoint)
I was wondering if I can pass the same binding and endpoint that I have in app.config so that I don't have to include either in app.config and web.config.
Yes, you can create these classes without having matching configuration in the main .config file. Where you get that configuration is up to you; it could be App.config, a YML configuration file, a database, etc. As long as your code satisfies the constructor requirements for the classes you're instantiating, you'll be fine.
With WCF, everything defined in your configuration file can be done programmatically.
You just need to create the objects needed to instantiate your client. Depending on the WCF features you want your application to be leveraging, you'll need classes like EndpointAddress, AddressHeaderCollection, Uri, EndpointIdentity (DnsEndpointIdentity or SpnEndpointIdentity), Binding (WSHttpBinding, NetTcpBinding etc.). And you might want to have these objects populated from a decoupled, centralized configuration store such as a database.
I have the following scenario:
There is a complex object that is residing in the standalone class library and some of the object properties have default values.
The object is argument for WCF public method.
I instantiate this object on the client of WCF, assign values to properties and pass it to the WCF public method.
The WCF method on service side accepts it and does whatever.
My problem is that when I instantiate the object on the client property default values are not available for me to use and I have to assign them in code again.
I looked through the past questions on the topic here and did not find anything related to my scenario. I don't really have data contract for the argument although on the client my object gets instantiated not from the class library itself but from the service reference, like WCFServiceReference.MyClass (otherwise WCF method can not accept it as argument).
I would really like to have all those default values to be available on the client.
I would appreciate any assistance.
Thanks!
With your approach -- using the service proxy classes -- the client only gets the properties marked with DataMember. That's why the default values you assign don't appear in the client -- that code is not serialized, so it's not sent with the WCF service.
If you want to share code, you can do it by declaring your DataContract classes in a separate class library. Have the WCF service and the client both reference that library.