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.
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 am trying to write some code in C# that will call a WCF service on the fly by importing the WSDL, examining it and then making calls to it dynamically.
The service I am calling can change from time to time - so if it does I want my client to know about new methods and new input parameters and output parameters to the calls, without rebuilding my client.
One possible solution to this is to import and compile a service reference on the fly.
Outlined here: Creating an assembly on the fly from a WSDL
I would like to avoid the generation of an assembly and then reflecting over it if possible.
I looked into the code of the dynamic proxy in the link and they use a framework class to do the import. This class is the WsdlImporter. So I had thought great - I can use that and examine the WSDL schema and determine what calls are present and what inputs and outputs are available.
The problem is that the type information is missing in the MessagePartDescription objects that the WsdlImporter creates. Apparently this is missing because it cannot find the types yet - see the response to the question from Brian.
So any advice on how I should proceed? Am I completely on the wrong track here?
This is probably not an answer but I will post it as one to fully describe my opinion.
Dynamic proxy:
IMO this is example of wrong usage of technology. It is elementary behavior of WSDL - if it changes you have to change client or you have to make good WSDL versioning and create new client.
You still have to somehow say your client to get WSDL - does it mean that you will parse WSDL before each call? Doesn't seem like a good idea.
Information about types is really not part of WSDL because by default WSDL is generated as interoperable. CLR types are not operation needed for interoperability. When you create service proxy by Add service reference or Svcutil it will generate code for types defined in WSDL. That code then need to be compiled.
You can try to use NetDataContractSerializer instead of default DataContractSerializer. NetDataContractSerializer adds CLR type information into WSDL but I still expect that new types must be known to your clients - it means deploying new assembly with types and use it by clients. This almost sounds like same approach when simply deploying assembly with new static client proxy.
Dynamic WF client
I also don't see too much usage of this architecture - you still need to change client to reflect new WF steps, don't you?
Changing the WF
Are we talking about Windows Workflow foundation? I can hardly imagine scenario where you create WF, expose it as a service and then change it. When you expose WF as service you are probably defining long running WF. Long running WFs use persistance which is based on serialization (at least in WF 3.5 but I believe it is same in WF 4). When you change WF definition, all persisted WFs are most probably doomed because they will never ever deserialize. This situation is usually solved by parallel deployment of new and old version where old version is only used to finish incomplete WFs. Again it means new clients.
If you look at the problem from a different angle. Do you need to regenerate the proxy each time or do you need a contract that continues to work when things change?
WCF has a mechanism for this IExtensibleDataContracts see: http://msdn.microsoft.com/en-us/library/ms731083%28v=VS.100%29.aspx
Best practices for versioning of contracts can be found here
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.
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.
I'm in the unfortunate situation where I need to consume web services that do not have a contract defined, as per normal SOA practices. This means that I need to guard against changes in the web services that break my web references. In the past, breaking changes in new web services versions such as the alteration of enumeration values have caused difficult to debug failures.
I'm using Web References to access the web services. I'm mostly consuming ASMX end points.
The sensible way to guard against breaking changes seems to be to check the endpoint for each web service, ensuring that the WSDL defined for the service matches the current endpoint schema. I'd like to do this at build time, and possibly also upon the application start up. Preferably the check would only fail for breaking changes, meaning that the addition of new elements to the endpoint schema would be okay.
One way to do this would be to generate a temporary WSDL from the endpoint, and verify that each XML element in the existing WSDL is contained within the temporary WSDL. But this seems fiddly, and I wonder if there is existing tooling, or a better way of doing this.
Thanks for your help and suggestions.
Check this question - it was asked for the same purpose. Mind you that service compatibility is a tricky issue and comparing even WSDL would only mean that you are guarding against syntactical changes. There is no way to detect semantical changes in service contract/implementation - only correct way would service offers versioning and then providing method to see if client is version compatible or not.