I have changed a former WCF one-way service to a duplex service so I can implement callbacks.
My actual problem is since that change, every piece of code that instanciates the service proxy needs to be modified to pass an instance context as parameter into the constructor.
There are many, many places in a few different projects that make use of that service. Everyone of them is now broken.
Will I be forced to go back in every proxy instanciation and pass an instance context into the constructor ? Can I avoid this ?
Simply speaking - no you cannot avoid this.. Presumably you need the duplex service for one WCF call to be able to callback... I would probably just create a separate method on the interface rather than changing the existing one so that you don't break the contract between service and client.
Related
Lets say I need to call multiple services that insert some records with EF in the same transaction which are for inserting Person and Unit.
I'm uncertain for whether I should create a new operation contract named AddPersonAndUnit and use TransactionScope in that method and calling it from the client OR don't create any additional method and just use TransactionScope in the client (ASP.NET MVC client) and call AddPerson and AddUnit which are already existing.
For single responsibility and moving all business logic into service layer, I think defining an extra method in service layer and calling it from the client seems a better choice but on the other hand just calling these multiple methods from the client requires less effort.
What do you think with the respect of a good design choice? Do you think dealing with the transactions in client is "bad"? Is it worth it to create a new method for this?
Based on your question, you're having two projects (ASP.NET MVC & WCF) and you want to make sure Person and Unit are being inserted/updated transactionally
Taking those two as inputs
Let's do quick analysis about option 1 (Use TransactionScope in client code (proxy class))
Efforts needed
Modify Service Contract classes (OperationContract and ServiceBehavior) to support transaction
Decorating existing methods (OperationBehavior) to suppor transaction
Modify binding config
Re-config client binding configuration
PROS (CLAIM TO BE):
Requires less efforts => As described in point 1., in my opinion, it's difficult to say this method requires less efforts to implement unless everything was is in place
CONS:
Since both application code (MVC) and service code (WCF) are being controlled fully by you, you can make sure that you ALWAYS use the transaction when insert/update Person and Unit. However, I would prefer to make it as black-box service, so that I could expose it to other 3rd client or give the service to another developer to use without worrying about data inconsistency (what if they forgot/intentionally skip the transaction?). Even though you can force the client to ALWAYS use transaction when calling the web services (by using TransactionFlowOption.Mandatory option), I think the good practice is only expose minimal service for client to use
Single Responsibility is also another concern
Duplicate codes (you will need to copy the code over and over every time you want to insert Person & Unit)
Hope it helps,
Sorry for bad English
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?
I am writing a dll that is referencing to some WCF service.
The dll is functioning as a Gateway of the service and all calls are going through it.
Probably there can be concurrent calls .
I have referenced the service but now I cannot decide how to write the wrapper functions correctly.
Is there some example or best practice for this functionality.
I would make wrapper that matches the web service interface. It would also be a good idea to wrap up all of the objects exposed. Basically create a proxy. What I find really useful for this type of thing is to create an interface that matches the API and implement that. That way, you can create a dummy version of the DLL for testing without the overhead (or potential costs) associated with the WCF call. It would also make it much simpler if you need to replace the WCF call with an alternate provider in the future.
As an example, lets assume that we have an WCF service to an external provider for processing a payment. Something like this:
void ProcessPayment(float amount);
We could easily hook this into our code. The problem is that a simple change to the interface would result in us having to make changes everywhere the code is referenced. The same would be necessary if we changed providers to someone else, even if the interface was almost identical. Adding something like a simple interface:
interface IPaymentProvider
{
void ProcessPayment(float amount);
}
Would completely decouple our code from the WCF service. We could easily build a class like this:
class PaymentProviderAWrapper : IPaymentProvider
{
void ProcessPayment()
{
// Call the WCF service
}
}
That we could load dynamically with a factory or dependency injection framework like Spring.NET. Changing to a provider B would be as simple as creating a new wrapper:
class PaymentProviderBWrapper : IPaymentProvider
{
void ProcessPayment()
{
// Call provider B's Native DLL
}
}
Switching your code from provider A to B would be as simple as changing a configuration setting.
Even if we compiled the library directly into our code, all we would need to do is change the construction logic to use the new library. The rest of our application would not change at all. Just a simple recompile.
In response to Graymatter's answer I don't see what the difference is between calling a service wrapper which exposes the same calls and then forwards the calls to the real service, and just calling the service, assuming a one-to-one mapping on individual calls and no change in transport binding.
The only reason you would want to create a wrapper in the first place is that the interface exposed in some way does not meet your requirement on it's own. There are several reasons you may want to do this but a few common ones:
Protocol translation - the service is not exposed across the correct transport binding for your needs
Service Composition - the interface operations are too granular and don't represent business-level operations.
Authentication - perhaps you require an authentication layer on top of the endpoint you are consuming.
So how to wrap the service endpoint depends on why you want to wrap the service...
I have a class library (c#) with many methods that call the same web service (asmx).
What is the best practice for instantiating the web service.
Instantiate the web service once and pass it as a parameter to each method
Or instantiate and dispose the web service in each method.
What you are instantiating is a local proxy class that calls the service, so it isn't as costly as you may think.
As web services are supposed to be stateless, either method would work. I doubt you will see much of a difference in performance.
It seams like a bad practice to make a new instance of the service, hook up complete events each time you have to call a service method
usually i make an instance variable
and then instantiate the service in the constructor and hook up all complete events there
and only call the methods when needed
this approach works well, except if you do it in an User-control it breaks the Visual Studio Designer
I just wanna learn why I can't static web methods in web services ? Why is it restricted ?
Can some body give me concise explanation of this.
The answer is: because you can't.
It's not designed that way. The design is that an instance of the web service class will be created, and then an instance method will be called.
I can only guess why Microsoft designed it that way. To know for sure, you'd have to ask them. Consider:
There's no particular benefit to permitting static methods. Anything you can do with a static method, you can also do with an instance method.
A [WebService] class is not meant to be some arbitrary class that happens to be used as a web service. It's meant to be a class that you created for the purpose of exposing web service operations. As such, there is no need to support classes that already exist and already have static methods.
The SOAP Header implementation permits your class to contain an instance field of a type deriving from the SoapHeader class. This field will be filled with an incoming SOAP header and/or will contain the SOAP Header to be returned. You could not do this with a static field, as it would be overwritten with each request.
As I said, these are all guesses. The correct answer to the question is, "you can't because that's how Microsoft designed it. If you want to know why they designed it that way, you need to ask them".
FWIW, I just checked, and it does not appear that WCF permits static methods to be operations either.
When a client creates an object for your web service, what they are really creating is a proxy object to that web service. This proxy object handles things like opening and closing your connections for you as well as all the overhead of actually working with the web service. A static method call would be difficult to manage. The "static proxy" for lack of a better word would have to do all of things that the instance of the proxy object is doing each and every time a client called one of the static methods, thus adding massive overhead.