We have a set of ASMX style web services which were created using the contract first paradigm by having WSDLs and XSDs supplied provided from an outside source.
We want to expose WCF services based on these WSDLs, but in the mean time we are also required to continue to provide ASMX services based on the supplied WSDLs.
I am curious if there is a way to use a shared Interface based on the WSDLs and/or a shared set of data objects that are generated based on the XSDs... Or another option was possibly wrapping the WCF service with an ASMX...
Any suggestions or previous experience with supporting both to make this transition period easier without entirely reinventing the wheel for both services?
Absolutely, it's totally possible.
The best way to do it is to have your WCF and ASMX services simply pass the request on to an internal class defined in an assembly referenced by both the ASMX and WCF service.
A refactor for your specific case to follow this paradigm would be trivial for nearly all cases.
Related
I am new to WCF service. I am aware about three ways to generate proxies.
Using Service reference
Using SvcUtil
Using ClientBase
But I am confused in which case I should use which type. In my case I have to generate proxies for third party service for which I don't have service code. I don't want to use add service reference because it gives me following issue. Mentioned in this stackoverflow question. So I want to use clientBase. But I think I cannot use it without using service reference. I am pretty much confused when should we choose which kind of proxies.
In my case I have to generate proxies for third party service for which I don't have service code.
I will have multiple apps using this service.
In that case you are better off using SvcUtil because it can generate a single library that all of your projects can use, even if they are .NET libraries. After it is generated you can always go in and tweak it.
Add service reference on the other hand is fine for a single .exe but as you have discovered, is annoying for multiple apps as you need to repeat the process and you end up with multiple definitions of WCF types that is just going to increase maintenance.
Just be sure to leave WCF client config in the app.config of your applications and not your app.config of your class library (as the former may not be read).
If your vendor had followed "WCF the Manual Way… the Right Way" it would have made your life easier.
SOAP purists would argue however that the only thing the vendor provides is a SOAP WSDL XML file from which you are required to generate your types anyway. (sadly, the default behaviour in .NET is back-to-front)
I have a set of services I want to be able to access via one end point altogether.
Now I want to build something in wcf rather than use an existing framework/software so that is out of the question.
Suppose I have 10 contracts each representing a contract of an indepedent service that I want to "route" to, what direction should I go?
public partial class ServiceBus : ICardsService
{
//Proxy
CMSClient cards = new CMSClient();
public int methodExample()
{
return cards.methodExample();
}
So far I've tried using a partial class "ServiceBus" that implements each contract but then I have more than a few (60+) recurrences of identical function signatures so I think I should think in a different angle.
Anyone got an idea of what I should do? or what direction to research? currently I'm trying to use a normal wcf service that's going to be configured with a lot of client end points directing to each of the services it routes TO - and one endpoint for the 'application' to consume.
I'm rather new at wcf so anything that may seem too trivial to mention please do mention it anyway.
Thanks in advance.
I have a set of services I want to be able to access via one end point
altogether.
...
So far I've tried using a partial class "ServiceBus" that implements
each contract
It's questionable whether this kind of "service aggregation" pattern should be achieved by condensing multiple endpoints into an uber facade endpoint. Even when implemented well, this will still result in a brittle single failure point in your solution.
Suppose I have 10 contracts each representing a contract of an
indepedent service that I want to "route" to, what direction should I
go?
Stated broadly, your aim seems to be to decouple the caller and service so that the caller makes a call and based on the call context the call is routed the relevant services.
One approach would be to do this call mediation on the client side. This is an unusual approach but would involve creating a "service bus" assembly containing the capability to dynamically call a service at run-time, based on some kind of configurable metadata.
The client code would consume the assembly in-process, and at run-time call into the assembly, which would then make a call to the metadata store, retrieving the contract, binding, and address information for the relevant service, construct a WCF channel, and return it to the client. The client can then happily make calls against the channel and dispose it when finished.
An alternative is to do the call mediation remotely and luckily WCF does provide a routing service for this kind of thing. This allows you to achieve the service aggregation pattern you are proposing, but in a way which is fully configurable so your overall solution will be less brittle. You will still have a single failure point however, unless you load balance the router service.
I'm not sure about making it client side as I can't access some of the
applications (external apis) that are connecting to our service
Well, any solution you choose will likely involve some consumer rewrite - this is almost unavoidable.
I need to make it simple for the programmers using our api
This does not rule out a client side library approach. In fact in some ways this will make it really easy for the developers, all they will need to do is grab a nuget package, wire it up and start calling it. However I agree it's an unusual approach and would also generate a lot of work for you.
I want to implement the aggregation service with one endpoint for a
few contracts
Then you need to find a way to avoid having to implment multiple duplicate (or redundant) service operations in a single service implementation.
The simplest way would probably be to define a completely new service contract which exposes only those operations distinct to each of the services, and additionally a single instance of each of the redundant operations. Then you would need to have some internal routing logic to call the backing service operations depending on what the caller wanted to do. On second thoughts not so simple I think.
Do you have any examples of a distinct service operation and a redundant one?
I have description of my Application Services using my fancy classes (ServiceDescription class that contains collection of ServiceMethod description, for simplification).
Now, I want to expose one Application Service as one WCF Service (one Contract). The current solution is very lame - I have console application that generates *.svc file for each Application Service (ServiceDescription). There is one method (Operation) generated for one ServiceMethod.
This works well but I would like to make it better. It could be improved using T4 template but I'm sure that there is still better way in WCF.
I would still like to have one *.svc file per one Application Service but I don't want to generate methods (for corresponding Application Service methods).
I'm sure that there must be some interfaces that allow to discover operations dynamically, at runtime. Maybe IContractBehavior...
Thanks.
EDIT1:
I don't want to use generic operation contract because I would like to have the ability to generate service proxy with all operations.
I'm sure that if I write WCF service and operations by hand then WCF uses reflection to discover the operations in the service.
Now, I would like to customize this point in order not to use reflection, just use my "operations discovering code" instead.
I think there is nothing wrong with static code generation in that case. In my opinion, it is a better solution than dynamic generation of contracts. Keep in mind that your contract is the only evidence you have/provide that a service is hosting a particular set operations.
The main issue I see about the dynamic approach is about versioning and compatibility. If everything is dynamically generated, you may end up transparently pushing breaking changes into the system and create some problems with existing clients.
If you have a code generator when you plan on implementing some changes in the application services, it will be easier to remember that the changes you make on the services may have a huge impact.
But if you really want to dynamically handle messages, you could use a generic operation contract (with the Action property set to *), and manually route the messages to the application services.
Keep in mind that you would lose the ability to generate from the service a proxy containing a list of operations available.
A project I am working on requires a structure as such:
{BasePrefix}/Application/{id}/Security/Users/{userId}
{BasePrefix}/Application/{id}/Objects/{objectId}
etc.
Application.svc would be end up being my WCF Web Service. I tried to convince them to do:
{BasePrefix}/Security/Application/{id}/Users/{userId}
This would allow me to have multiple WCF Web Services as Security.svc, Objects.svc, etc.
They still want it all under application so instead of throwing all my service methods into a single file, I wanted to break it out by functionality and use partial classes to combine it all into one resource.
I saw an article about how to do this here: http://www.meineck.net/2008/04/wcf-hosting-multiple-wcf-services-as.html
The developer in that article is working with a Net TCP binding, however, so I am not sure if this will work with a WebHttpBinding and how IIS will handle the multiple resources.
Has anyone done this? Is the article I linked a good resource? Or is there a better alternative method to achieve the same results?
The methodology in the linked article is sound, and will work for bindings other than netTcpBinding (including webHttpBinding, wsHttpBinding and so on).
However, I believe what you are trying to do is use a URL rewriting scheme (probably using the UriTemplate property), which is subtly different from what that article actually talks about. It is referring to the creation and implementation of multiple interfaces, by the same service, and mapping each interface to its own endpoint.
The approach does not work with a single endpoint. So if your endpoint is {BasePrefix}/Application, that can only be mapped to one interface (say IApplicationService) in the configuration.
In your case, I don't think you'll be able to go the multiple-interface route because you need to have just one endpoint. So you'll still need a single monolithic interface with all of the methods (ugly), but you could in theory use partial classes to split up the implementation of those methods into logical groups. It's better, but not exactly ideal.
You were on the right track with your original assessment. If your scheme looked like:
{BasePrefix}/Security/Application/{id}/Users/{userId}
{BasePrefix}/Repository/Application/{id}/Objects/{objectId}
Then you would be able to use either of the approaches - either have multiple services, or have a single service that implements multiple interfaces and hosts multiple endpoints.
What the code/configuration in that article is really designed to do is enable a single service instance to host multiple endpoints. The main reason to do this is if you would otherwise have to duplicate a lot of code between services. Unfortunately that's not your goal here, so you will either have to push harder for your proposed URI scheme, or deal with a monolithic service contract (interface) and do the best you can to keep the implementation clean through #region directives and/or partial classes.
I'm adding a method overload to an asmx web service written in C#, and in order to publish it I need to change the WebServiceBinding attribute of the service to the above. Doing so seems pretty harmless (the web service will only be consumed by applications written in house, at least in the foreseeable future), but am I missing some implications of that choice?
To implement method overloading in webservices first you must set the MessageName
attribute of your webservice then set your webservice binding ConformsTo
attribute to WsiProfiles.None and that’s it! Note that you can do second step
in your Web.Config file for all webservices. (according to this blog post).
Just to wrap things up here (after #Niklas's query), I decided that worrying too much about this on an internal-only web service amounted to micro-optimization.
Specifically, I determined that as long as no one is going to generate a proxy from my WSDL for the service and as long as all of the consumers are well-known (and in this case under my control), the WS-I profile I conform to is irrelevant.