Say i'm having a web service that accepts two arguments and that is being called/consume in my application. Now after some time, the web service changes and accepts three arguments, hence in my application, would that be throwing an error, or i need to just update the web reference, or i need to recreate a web serivce or would that be working fine?
Let me know if any doubts
Thanks!
You could add optional parameters where if a parameter value isn't given to the method a default value is used.
From a "pure" architectural aspect, you should never change the signature of a method of a service once it's in use. You should version by creating a new method with a different namespace. But staying pure is sometimes difficult to do.
In your case you need to update the Web reference in the client application and then modify the code to pass in the appropriate parameter to the method in the service proxy.
Related
so i want to create some service that accesses external API, and i want to cache common requests from the API inside of that service, it depends on 3 other services, but i want to give it its own instance of cache, MemoryDistributedCache might later be changed for something else
services.AddSingleton<ISomeApi, SomeApi>(provider => new SomeApi(
Configuration.Get<Options>(),
new MemoryDistributedCache(new MemoryCache(new MemoryCacheOptions())),
provider.GetService<ILogger<SomeApi>>()
));
now from my Controllers i can access the api via DI, it works nicely but im not sure if its some sort of an anti-pattern or if there are better ways of doing it
i mean the real problem is separating the internal cache, requesting
IDistributedMemory from one service would give me the same object as if i request it from another service, they must be separated
This sounds like something you could use a proxy or decorator pattern for. The basic problem is that you have a service that does some data access, and another service responsible for caching the results of the first service. I realize you're not using a repository per se, but nonetheless the CachedRepository pattern should work for your needs. See here:
http://ardalis.com/introducing-the-cachedrepository-pattern
and
http://ardalis.com/building-a-cachedrepository-via-strategy-pattern
You can write your cached implementation such that it takes in the actual SomeApi type in its constructor if you don't need that part of the design to be flexible.
We are mixing workflows, a workflow using receive activity's more at the end. But at the start we want to pass in some arguments (not using a receive activity!)
Our workflows are already being created and resumed using a dynamic endpoint with IWorkflowCreation and a class derived from WorkflowHostingEndpoint. In the OnGetCreationContext the creationgContext is filled with WorkflowArguments and the workflow runs. At a later part the receive activity's are creating a bookmark which can be resumed with a message. All seems nice.
But in a xamlx there are no WorkflowArguments, i understand why, except that i want them anyway. I though about an activity in which i can write some code to get the Arguments myself, but i do need some help here.
Or is there another way to pass along the WorkflowArguments into a xamls without using Messaging?
You can't pass arguments into a starting workflow service except through the SOAP message that starts it. But there is nothing preventing you from reading any properties in your workflow service. So it is perfectly fine to do read settings or something similar instead of passing them in at startup.
We have solved this exact situation by creating another WCF service which sits alongside our xamlx service on a slightly different url (e.g. /WorkflowMetadata) and this is where we implement a service method that returns a dictionary of string, type.
In the implementation of this service we simply read the xamlx and determine the arguments.
This is what we use to interrogate a target workflow in an activity designer when creating something like a launch-workflow activity.
Creating an activity will not work as that activity will need an instance in order to run. All you want is some metadata about the xamlx service. And if you are using a WorkflowCreationEndpoint to construct a creation context then you are probably only allowing a dictionary of string, object as the start parameters. Therefore standard metadata will not work. This left us with the only option being to provide another service beside the workflow which serves metadata.
Background here: http://blog.petegoo.com/index.php/2011/09/02/building-an-enterprise-workflow-system-with-wf4/
I call the following local WCF Client service.
var Key = 1000;
FormServiceClient formService = new FormServiceClient("WSHttpBinding_IFormService");
And I call
formService.GetCaseData(Key);
The Key value is not getting passed into the service via my asp.net application.
If I used WCF Test Client then there is no problem working.
When I hit this step--> formService.GetCaseData(Key);
The Key parameter has a value of 1000.
Once I get to the Service side, it has a value of 0.
I noticed that if I call an method that returns a simple POCO class it works fine. I am trying to return an Entity Domain object. Could this be the problem?
I have experienced the same problem. Although I have not yet found a solution, anyone reading this may want to unclick 'show my code only'. If you do you may see a System.Runtime.Fx.Async.Thunk.UnhandledExceptionFrame(AsyncResult) or something similar. If this is the case, and you are using ASP.NET with .NET 4.0+ the problem is likely a synchornization conflict between WCF and ASP that occurs only in debugging, and only when passing data through interfaces. However I know of no solutions to this problem.
I have two Biztalk applications, each of which expose a webservice port,
I'm consuming them in an ASP.NET client using the 'Add service reference' tool from within the VS2010 GUI to generate the proxies.
But the proxy interface is slightly different in both. One takes two parameters, returns the 'response' via a parameter using the out keyword and has a void return type,
the other takes one parameter and returns the response using a typed return value.
I'm confused as to what is causing the difference in behavior, is something I'm doing as part of the creation of the references (as far as I can tell I've used the same process) or is it something about the server/WSDL I'm consuming?
EDIT -As per Grahams comment the type of proxy interface generated seems to depend on whether there is a namespace or not. I'll give the answer to whoever can put together the clearest description of what exactly is happening there.
As noted in the comments, the inclusing of a namespace in one of the services is what was triggering the difference in the proxy code generation. It's still not clear exactly why this is the case however.
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.