Is it possible to add operation contracts to a rest service during the runtime?
For instance we have a service which is available under the endpoint: www.mywebsite.com has already one operationContract: getName.
But now I want to add during the runtime two additional operationContracts: like getAdress and GetNumber.
The main problem is how to let clients to know about new service contracts.
I think you can add new service endpoints at runtime by creating ServiceHost instances. Service will listenting to some different addresses. Those endpoints will use different service contracts (interfaces).
I don't think you will construct and implement interfaces dynamically (but you can in .net). You will probably use some predefined interfaces. In this case you should inform clients somehow about new service contract and address. To pass and consume such metadata you can:
1) Use duplex methods (service to client call direction) of some 'static' maintenance service - to bring service metadata to client in custom format;
2) Use periodical client calls (polling) to this maintenance service - for same purpose;
3) Use periodical web scanning (by address range) and parse wsdl to build client proxy at runtime. You can run "svcutil /sc ..." at runtime to generate code or use custom technic (this or this can help);
4) Use intermediate service to orchestrate both service and clients (complex but powerful approach, this can help);
5) Use wcf discovery in addition (not an easy way too);
6) Use combination of those methods.
p.s. You can use one interface but inform client when service supports (implements) certain method. It would be the easiest way.
Related
Does MOQ give access to Castle's DynamicProxy generation? Or are there configurable static methods or something in the Castle namespace that would allow me to tune MOQ's proxy gen behavior?
Some Background
I am Mocking a WCF Service endpoint (IWhatever). WCF automatically adds Async call back options for methods (e.g. IWhatever.DoWork() is also realized as IWhatever.DoWorkAsync()).
I'm looking to use the Mock<IWhatever> object while self-hosting this service mock'd; basically spoof this external web service to my system. However, when [self-hosted] WCF tries to create a DoWorkAsync() method; it already exists... which ultimately throws errors when opening the self-hosted/mock'd IWhatever endpoint. ((NOTE: I don't have access to original contract to use directly)).
Sooo.. looks like Castle DynamicProxy allows for one to define which methods should be generated (see: http://kozmic.net/2009/01/17/castle-dynamic-proxy-tutorial-part-iii-selecting-which-methods-to/). I was thinking I would use to not intercept calls on methods ending with "[...]Async". However I don't see where I would add this customization rule in the proxy generation within MOQ; hence my question.
I have an application that consists of a web application, and mutliple windows services, only one windows service is installed depending on what version of the backend sofware is used.
Currently, Data is saved by the web app in a database, then the relevant service is installed and this picks up the data and posts it in to the backend system that is installed.
I want to change this to use WCF services so the resulting data is returned directly to the web app.
I have not used WCF services before but Im assuming I can do something like this.
WebApp.Objects.Dll - contains Database objects, eg PurchaseOrder object
WebApp.Service.Contracts.dll - here I can describe the service methods, this will reference the WebApp.Objects.dll so I can take a PurchaseOrder object as a parameter
WebApp.Service.2011.dll - This will be the actual service for the 2011 version of the backend system, this will reference the WebApp.Service.Contracts dll
WebApp.Service.2012.dll - This will be the actual service for the 2012 version of the backend system, this will reference the WebApp.Service.Contracts dll
So, my question is, does the web app need to know the specifics about what backend WCF service is used? I just want to call a service with the specified Interface and not care about how its implemented or what it does internally, but just to return the purchase order that was created in the backend system (whether it return an interface or a concrete class)
Will i be able to create a service client without needing to know whether its the 2011, or 2012 WCF service being used?
As long as you are able to use the exact same contract for all the versions the web application does not need to know which version of the WCF service it is accessing.
In the configuration of the web application, you specify the URL and the contract. However, besides the contract there might be other differences between the services. In an extreme example this might mean that v2011 uses a different binding as v2012 of the backend - which is not very likely from your description. But also subtle differences in the configuration or the behavior of the services should be addressed in the configuration files. E.g. if v2012 needs longer for an action as v2011 does, the timeouts need to be configured so that the longer time of v2012 does not lead to an expiration.
I've created several services by wrapping the WorkflowServiceHost in a WCF service; using WorkflowHostingEndpoint. Doing this I was able to define my service contract and create proxy classes to connect to those services.
I'm now creating a service in which I want to use the WF4 messaging activities and again self host the service. I also REALLY want to manually create my proxy classes without using the ServiceReference in VS2010 or ServiceUtil...
I've seen some references that use the Send Activity in the Service client but I'd like to be able to use a more "WCF-like" proxy created directly against the service contract like I've done with the other services. How can I do that? Is there anywhere a xamlX (or xaml with messaging activities) stores the interface contract that I can use to generate a proxy manually?
NOTE: I don't want to use the Send activity as described in the WF_WCF_Samples.
UPDATE:
I tried creating an interface identical to the workflow receive activity before posting this question; but I keep getting the following error:
The message with Action 'http://tempuri.org/ISvrClientService/Create'
cannot be processed at the receiver, due to a ContractFilter mismatch
at the EndpointDispatcher. This may be because of either a contract
mismatch (mismatched Actions between sender and receiver) or a
binding/security mismatch between the sender and the receiver. Check
that sender and receiver have the same contract and the same binding
(including security requirements, e.g. Message, Transport, None).
Thanks!
There is no need to use the Send activity. When you host a workflow service you are hosting a SOAP endpoint, the only difference is the implementation but that is a private detail. You can create a proxy object using ChannelFactory just like with any other WCF service.
var factory = new ChannelFactory<IYourService>();
var proxy = factory.CreateChannel();
The IYourService interface is somethign you have to hand craft. There isn't one on the server, it is done in a workflow, so you have to code up the identical contract.
I've done this successfully with channel factory and manually created interfaces. The trick was in matching-up the reply/send in/out parameters names not just type signature.
This is particularly crucial if you have bookmarks with correlation in your workflow.
I have two work flow that be hosted through WorkflowServiceHost and those contain some Receive activity that expose services to out.
some services that my workflowservices must expose is general, for example suppose there is a monitorring service that return Tracking Information about one wf instance.
Solution 1 : in any workflow definition there is a receive activity that return Tracking Information.
but i look for another solution without defining this functionality as activity.
notice that i dont want use another service to expose these functionality, i want expose these functionality in same work flow service
Tanks
(sorry for bad english writing)
If you want to expose everything as one service you have 2 options:
Add the tracking requests to the workflow service as you suggest
Create a wrapper service, a regular WCF .svc file, and forward the requests to the workflow as needed and handle the tracking outside of the workflow.
If you really want to expose just a single external service I would go for the second option. That said, I normally just expose 2 services as they are different things and services are for machine consumption and not human consumption so the 2 URL's are no problem.
I have an ASP.NET MVC web app whose controllers use WCF to call into the domain model on a different server. The domain code needs to talk to a database and access to the database server isn't always possible from web servers (depends on the customer site) hence the use of WCF to get to a place where my code is allowed to connect to the database server.
This is configurable so if the controllers are able to access the database server directly then I use local instances of the domain objects rather than use WCF.
Lets say I have a page asking for person details like age, name etc. This is a complex type that is a parameter on my WCF operation like this :
[OperationContract]
string SayHello( Person oPerson);
When I generate the client code (eg; by adding a service reference in my client) I get a separate Person class that fulfills the wcf contract. The client, an MVC web app, can use this client Person class as the view model and all is well. I pass that straight into the WCF client methods and it all works brilliantly.
If my mvc client app is configured to NOT use WCF I have a problem. If I am calling my domain objects directly from the controller (assume I have a domain access factory/provider setup) then I need the original Person class and not the wcf generated Person class. This results in my problem which is that I will have to perform mapping from one object to another if I don't use WCF
The main problem with this is that there are many domain objects that will need to be mapped and errors may be introduced such as new properties forgotten about in future changes
I'm learning and experimenting with WCF and MVC can you help me know what my options are in this scenario? I'm sure there will be an easy way out of this given the extensibility of WCF and MVC
Thanks
It appears that you are not actually trying to use a service-oriented architecture. In this case, you can place the domain objects into a single assembly, and share it between the WCF service and the clients. When creating the clients, use "Add Service Reference", and on the "Advanced" tab, choose "Share Types". Either choose to share all types, or choose the list of assemblies whose types you want to share.
Sound service-oriented-architecture dictates that you use message based communication regardless of whether your service is on another machine, in another process, in another appdomain, or in your appdomain. You can use different endpoints with different bindings to take advantage of the speed of the link (http, tcp, named pipes) based on the location of your service, but the code using that service would remain the same.
This may not be the easiest or least time-consuming answer, but one thing you can do is avoid using the "add service reference" option, and then copy your contract interfaces to your MVC application and initiate the connection to WCF manually without automatically creating a service proxy. This will allow you to use one set of classes for your model objects and you can control explicitly when to use WCF or not.
There's a good series of webcasts on WCF by Michele Leroux Bustamante, and I think in episode 2, she explains how to do exactly this. Check it out here: http://www.dasblonde.net/WCFWebcastSeries.aspx
Hope this helps!
One sound option is that you always use WCF, even if client and server are in the same process, as Aviad points out.
Another option is to define the service contracts on interfaces, and to put these, together with the data contracts into an assembly that is shared between client and server. In the client, don't use svcutil or a service reference; instead, use ClientFactory<T>.
This way, your client code will use the same interfaces and classes as the server.