I need to invoke WCF service 1 or WCF service 2, based on certain condition evaluated at runtime. Both the services are similar but hosted on different servers.
I have added two service references, NS1 and NS2 pointing to different urls. Current code already uses NS1. Considering this NS1 implementation has already been done at many places. What would be best way to refactor the code, to select dynamically which service has to be invoked ?
In general, it is considered a bad practice to program directly against the proxy generated by the svcutil.exe.
The best way is to wrap it in a class of your own and reference this class each time you require the service. This will also allow you to implement more advanced business logic such as routing (in your case) and other cross cutting concerns.
For example: you can now abstract from the application the strategy you are using to connect to the service, i.e. Service reference or ChannelFactory. You can easily share the service between different assemblies without ambiguity.
You are saying that you have much code written directly against NS1. Grind your teeth and wrap it. It is a lot of dirty work but the risk is very low.
Having said the above, I wonder about the requirement itself, where a service calls another instance of itself on another server (if I got you right). This smells funny, what is the problem you are trying to solve?
Related
I am having problems in working with the Namespaces in the WCF. I have never done it before. I have tried a lot to find solution on the google. But still I am not able to find a solution for it.
I have written a WCF service which is divided in 3 projects and additionally i have created a models project:
Contracts (ServiceContract)
Service (Codebehind)
Host (ServiceHost)
Models (DataContract classes)
When I am hosting the service in IIS, it is generating the WSDL fine but there are namespaces which I have not defined as below:
http://schemas.microsoft.com/2003/10/Serialization/
http://schemas.datacontract.org/2004/07/My.Models
The problem is that I want to access all my service contracts and data contracts through same namespace only.
Because when the DataContract classes are generated in the proxy class, it is being duplicated. Mean if I have a class ClassA in my Models projects, then it is giving me 2 classes as ClassA and ClassA1.
I saw that in proxy class that these are there in the different namespace. So, I want to avoid that.
I also want to avoid ChannelFactory method, because there are a lot of OperationContract functions. So, don't want to code that much with hand but would like it to be auto generated in right fashion.
Any help is greatly appreciated. Thanks in advance.
I also want to avoid ChannelFactory method, because there are a lot of
OperationContract functions. So, don't want to code that much with
hand but would like it to be auto generated in right fashion.
This makes no sense at all. The ChannelFactory<T>.CreateInstance() method is much lighter than a wsdl-generated service proxy, and the amount of code you will have to write is comparible.
Service references are designed for when you're calling third party services which you have no control over or internal visability of.
There is aboslutely no situation I can think of where using a generated service reference is preferable to using ChannelFactory if you have access to the service definition assemblies.
This is especially the case for your requirement to manipulate the service wsdl in order to control code generation on the client side.
I am trying to improve the speed of a C# job, let's call it 'WidgetProcessor'. In one run, WidgetProcessor will process about 5,000 widgets and take about 12 hours to complete (about 8 seconds/widget).
WidgetProcessor makes references to 3 different web services and calls them multiple times for each widget processed. There are various performance/design improvements that can be made to the 'WidgetProcessor' program, but I want to test if the multiple web service calls over the network cause the job to run slow.
I have the source code for each of the three web services (and have access to all of the resources those web services use), and I'm wondering if there is a way to easily use the web service interfaces in WidgetProcessor by referencing the web service projects themselves (instead of calling the web service over the network). The web services are implemented in C#.
I would reference the service implementation classes directly, but the main problem I'm running into is that the web services have collectively about 100 data contracts and the public facing names are different than the implementation classes.
[DataContract(Name = "WidgetInfo")]
public class WidgetDataContract
{
// DataMembers
}
Thus, referencing implementations directly means I'd be making many code changes in WidgetProcessor. Rather, I'd like to use the service interfaces, so that code changes can stay at a minimum.
Basically, I want a service in my WidgetProcessor solution that looks and acts like a web service, but doesn't perform its operations over the network.
Is this even possible?
You can add adapter classes which subclass the implementation with the name specified in the datacontract:
public class WidgetInfo : WidgetDataContract { }
If you are finding the overhead of the service call to be overly expensive, you may see benefit of going to a different binding or serialization format. WCF can approach in-process speed when tuned properly.
Edit: If you are intent on not modifying any code, you do have a couple options, but I think they are solutions in search of a problem:
Mono.Cecil or Roslyn to automatically map between the classes pre- or post-build
For only the types, you could use TypeForwardedToAttribute, but property access is problematic. This may be dependent upon placing the svcutil generated classes in another assembly.
Use Castle to build dynamic proxies and map access based off of attributes
We are developing multiple web services in C# using WCF, but we´re new doing it.
So, for what we have read and learnt, this is our approach:
We have a class library that we called CommonLibrary that has a few classes that are going to be used on all our services (language stuff, type of user connected and a common object that all the services are meant to return).
We have another class library called SecurityLibrary which validates the user that is consuming the method.
At the moment we have 2 services that are almost at 90% finished, both of them use CommonLibrary and SecurityLibrary.
Now the questions:
Is this a bad approach?
Are we violating the SOA principles of encapsulation and autonomy by using common/shared library with each of our services?
A third person told us to copy all the code of those libraries on each of our services so we have a 100% autonomous service, is this the right way? I think is hard for maintenance and shows a lot of duplicity. Any update made on one has to be replicated or merged on those other services...
No, it is not a bad approach?
If using libaries in your service, you should also keep away from the .NET-library. I am wonding why you are thinking that a service process is only allowed to exist of only one assembly.
Furthermore, copy-paste code is a very, very bad habbit. It is known as a anti-design-pattern. I duplicates the maintainance and also all the bugs inside it.
Sharing libaries does not make your service less "autonomous". I think it could make them more compatible if they are sharing types.
A good service is just a process, existing of one or more (shared) assemblies, with a well defined service contract. This service contract is never allowed to be broken.
BTW: In my answer I did not include problems which shared assemblies in the GAC. That is a feature or problem shared by all processes, not only services.
I've just begun learning WCF, and I'm coming from a total non-web background.
I have built a 3-tier desktop application, which compiles into one exe, which runs locally.
Now I want to move the whole business logics layer to a centric server, and make the GUI a client application.
As far as I understand, WCF should be my solution, as indeed, it helped me achieved what I wanted.
I mange to run remote functions, which is the basic of what I need.
My problem now, is that I don't quite understand the architecture.
For example, one of my services, returns a data type (class), from my Business Logics layer.
This class automatically becomes available to the client through the WCF mechanism.
But the problem is, this class contains some methods, which i definitely do not want to expose to the client.
For example a Save method (saves to the db).
Further more, sometimes I don't even want to allow the client to change all the properties of the class, since this class might be sent to one of my services.
I do not want to re-validate the class instance in the service.
What should I do? Should I build another layer, restricted version of the Business Logics, which I expose to the client? Or is there any way expose only part of my class to the client, without restricting the server it self?
I know this is a basic question, but honestly i've searched a lot before asking here. My problem is I don't quite know what to search.
My second question is then, do you have any recommendation for any resource that can explain me this architecture...?
Typically, if you want to encapsulate your business layer, you would not want to expose the business objects directly. This is because you now have a de-coupled client and you don't necessarily want to have to update the client every time the business logic/properties change.
This is where Data Transfer Objects (DTO) come into play nicely. Usually, you want to have control over your contract (data and methods) that you expose. Therefore, you would explicitly make other objects (DTOs) that make up the transfer layer. Then, you can safely change your client and server code independently (as long as both still fulfill the contract objects).
This usually requires a little more mapping (before you send or receive on each side) but it is often worth it.
For WCF, your interfaces and classes marked with [ServiceContract] and your classes marked with [DataContract] usually make up this transfer layer.
In WCF to expose method to client you have to mark it with OperationContractAttribute. So if you don't want clients to use your Save method, just don't mark them with with this attribute.
More info here: http://msdn.microsoft.com/en-us/library/system.servicemodel.servicecontractattribute.aspx
Pretty much same thing with properties, but different attribute: DataMemberAttribute. If you don't wont client to see it, just don't mark them with it (DataMember attribute)
But the problem is, this class contains some methods, which i definitely do not want to expose to the client.
Are you able to provide an example of your class and interface code? If so I'm sure you might be able to get more specific answers.
For example a Save method (saves to the db).
One possible approach would be to separate your class into 2 classes. Define the properties in the first class and then use that class as the base class of your second class. Then use the second class to define the methods. This would allow you to return only the properties while allowing you to keep your code DRY.
Further more, sometimes I don't even want to allow the client to change all the properties of the class, since this class might be sent to one of my services.
I do not want to re-validate the class instance in the service.
While you are able to define logic in the get and set methods for each property I would highly recommend revalidating any input received between services simply because any future changes or errors in one service could potentially lead to larger problems across your application. In addition this also helps to ensure your application is more secure against any potential attacks.
Should I build another layer, restricted version of the Business Logics, which I expose to the client? Or is there any way expose only part of my class to the client, without restricting the server it self?
I agree with the above answers that you should be able to limit access to the different properties and methods using the data and method attributes within your interfaces.
My second question is then, do you have any recommendation for any resource that can explain me this architecture...?
If you are looking for inexpensive but highly valuable video based training I've found the courses that Pluralsight offers to be quite good for both architecture as well as WFC services (btw, I am not associated with them, just enjoyed their training).
I'm about to design my Web service API, most of the functions of my API is basically very simular to my web application.
Now the question is, should I create 1 single method and reuse them for both the web application and the web service api? (This seems to be the logical solution, however its very complicated; it's much easier to duplicate the method used by the web application, and keep both separate, ie one method for the web application and one method for the web service.)
How do you guys do it?
1) REUSE: one main method and reuse them for both web application and web service application (I like this but it's complicated)
WebAppMethodX --uses-->
COMMONFUNCTIONMETHOD_X
APIMethodX ---uses---->
COMMONFUNCTIONMETHOD_X
ie Commonfunctionmethod_x contains reusable set of common features
PRO: less code, less maintenance, less bugs.
CON: very complicated
2) DUPLICATE: two methods, one method for the web application and one method for the web service.
WebAppMethodX
APIMethodX
PRO: simple
CON: duplication = more code, more maintenance, more bugs!
Your use case will very likely be different for your public webservice API than for your internal application API. Create a common service project / tier and use that same tier from both your web app and your public-facing webservice API. Create a separate http-invokable method for each of your web app and your webservice.
It comes down to there being
1) different security concerns. For instance, it is nice (often required) to provide a sample client application making use of your public API so that others can easily get up to speed with what you've provided. That client API may need to pass object constructs that you provide them that have been stripped of internal, secure logic/content. (Remember that compiled C# might as well be clear text with Reflector!)
2) different needs and constraints. For instance, for an internal application call you're going to sometimes enforce different business rules vs. your public facing webservice API (often with the latter being much more constrained to scope).
If you design your business logic into your service layer and invoke those classes/methods well from your web project and your webservice project respectively you're going to have a lot of code reuse anyway without trying to overcomplicate things by mixing use cases.
One method. Otherwise when you find a bug and fix it in one, then forget to in the other... you will cry.
One method, in the web service, and have your web application call it.
I don't understand what "one main method" for both means. Web applications don't have a main method; they're deployed to an app server.
One other point to note: you should write your service in terms of a POCO interface. Once you do that, deployment becomes a choice you make.
It depends..
Normally, I would separate them. This way you remove interdependency between two high level processes. code reuse is good within a process but sometimes you want to be able to use a different app on the same service.
If the two are highly dependant on each other, however, you will want to reuse the same functions so that changing it in one place will change it in another. Thus avoiding more potential issues with the development process.