I have an existing WCF service.
Is it possible to add operation contract to the service interface and have the implementation in a workflow?
Or I absolutly need a seperate service interface for my workflow?
When you publish a WCF service you are publishing the interface and telling it what implementation to use. You can specify only one implementation, otherwise how would WCF know where to route which request. So in short you need to use a separate interface for your workflow services. That said, if you don't want to change your public facing API there is no reason you can't create a minimal implementation that just passes request on to your worklflow service.
Related
Using .NET Framework 3.5 C#, I am in the process of moving from SOAP-based Web Services to JSON-based WCF Services. All my web services derive from a common ServiceBase class with common functionality like session validation, client authentication, database connection, logging etc. and in all my web service method I call a common method on the base class using a single line of code to perform the common tasks
base.InitCallThread()
Q1: What is the best way to do the same or similar in WCF in order to avoid having to write hundreds of lines of repetitive code?
Q2: If I was to support the same interfaces with both SOAP-based Web Services and JSON-based WCF services in parallel, what would be the best way to share the same common functionality? I guess it is possible to share the http session b/w the two?
You should refactor your base class code into a separate class. Call that separate class from the base class in your ASMX services; in the WCF service, call it from each individual service, or use one of the WCF extensibility mechanisms to call it centrally.
WCF permits the same service to be exposed on multiple endpoints with different bindings. You can expose the same WCF service with basicHttpBinding for SOAP, at the same time as exposing a webHttpBinding for the JSON.
Q1: You can derive from the same ServiceBase class with common functionality as you had before. WCF does not limit you in this matter. It requires only implementing some interface
Q2: You can define multiple bindings through web.config (or programmatic) configuration.
I'm developing a .NET 2.0 client application that needs to connect to a WCF service. I add a web reference to a basicHttpBinding WCF service that we've developed and VS creates the proxy class and the config paraphenalia which is fine. The problem is that I only want to use a small fraction of the methods that the WCF service implements and not carry around the extra implementations that the client app doesn't need.
I was thinking of creating a different basicHttpBinding endpoint and put the methods there. Is there a way for only one endpoint of a WCF service to be referenced by a .NET 2.0 project?
Regards,
Frank
When you add a web reference to a service, you always get all the service methods. It's the service (implementation) that defines the scope of what ends up in the WSDL.
The only option to limit the scope of the method your client generates would be to create a second WCF service on the backend, which only implements those few methods that you want in your client - just having a second endpoint won't really help.
I have a win32 application that uses client side plugins and uses a Win32 Service via TCP/IP. I would like to also dynamically load assemblies on the WCF service based on the addition of new plugins. Currently I have to add the the ServiceContract and OperationContract to the Services class and IService interface and then re-compile. Is there a way to dynamically load the WCF assemblies and not have to generate the class and interface references? Can these be moved out of the WCF Win32 service into external classes?
I was wondering about this as well, but came to the conclusion that this was not a question of whether or not its possible, but should you do it? Even if you could generate the contract definitions dynamically, you still need to notify the client of the change, they in turn would need to regenerate the proxy in order to interact with the new service definition, and then provide an implementation dynamically. A better approach is to redesign your service so it implements a particular strategy (read Strategy pattern). The contract remains static, but the implementation changes based on client input. That way your service can dynamically load modules without your client being aware of it.
HTH.
Steve
I am developing a solution with multiple WCF services which all communicate among themselves, even though they are of different types. The services connect to one another through the ChannelFactory generic interface, and every service is hosted inside a ServiceHost.
My question is if it would be correct to use a callback contract among the servers to communicate with one another and if so how would such a solution look.
Currently I don't like the implementation because every service needs to host a couple of endpoints with different interfaces some for other services and some for other clients.
When I tried to implement the callback contract inside a service class that was hosted inside a ServiceHost it failed.
First of all, whenever you post a question saying, "it failed", you need to tell us in what way it failed. If there was an exception, then you need to post the entire exception, including all InnerException instances, by posting the result of ex.ToString().
To your problem, I'd implement a service contract that represents the part of each service that needs to talk to the other services. There would also be a callback contract associated with this service contract.
That way, it's as though each service operates a miniature service intended only for service-to-service communications. They can then each do their own thing with the information that is passed between the services.
So I already have a working implementation of StructureMap with the WCF service (including custom instance provider, behaviors, etc.)
When I try to have an object that is instantiated only once per user request, I use the InstanceScope.HttpContext and it throws because the context is null.
Do anyone have a proper way of doing that?
On the server-side of the WCF service? By default, WCF has nothing to do with ASP.NET and thus all your HttpContext etc. aren't there.
By default, your WCF services will be called on a "per-call" basis, e.g. each request gets a brand-new, separate, totally isolated instance of your service class. Why not just put those things into the service class as internal fields??
Or you might want to check out this blog post on how to abstract request state and providing sample implementations for ASP.NET (using HttpContext.Items) and WCF.