Is there any way to include documentation in the WSDL when publishing a WCF using "Biztalk WCF Publishing Wizard" or any other way?
The wsdl documentation tags are empty by default in the wsdl, example:
<wsdl:documentation>
<CreationInfo Created="2014-02-17 11:09:45Z"/>
</wsdl:documentation>
or
<wsdl:portType name="CustomerService">
<wsdl:documentation/>
<wsdl:operation name="RequestCustomerInfo">
<wsdl:documentation/>
....
Yes, but I'm ~95% sure what you asking can only be done with a custom Behavior.
Related
I was trying to consume an already written WCF service into my BizTalk orchestration. But while configuring the ports and port types for the consumption, found that the 'WCF service consumption wizard' in Visual Studio offers HTTP transport-type as the only option and no WCF-BasicHttp/WCF-WSHttp transport-type options are available.
However, we can always do the required WCF-BasicHttp/WCF-WSHttp settings by importing the required bindings file from the BizTalk Admin Console, Is there a programmatic way for the developers to do the same from inside the Visual Studio (instead of specifying those bindings later from the Admin Console)?
The binding files are just XML, so you can create those programmatically. Modify the XML as you see fit, either by hand (e.g., in the built-in XML editor) or by using some sort of custom code.
Typically we use multiple binding files per environment, including one that just works with everything on localhost for developers. You just pick the one that you want and import it into BizTalk or write a script automatically import it for you (such as after build).
You can also take a look BizTalk Deployment Framework. For more of that.
Michael Stephenson has a great post on using MSBuild to automate your deployments, including the BizTalk binding files, here.
How to create SOAP 1.1 file?
Is it xml file, or?
This is the file that I need to make.
When I copie theat cod in xml, an error occurs:XML Parsing Error: syntax error
POST /CommunicationOfficeService1_0/ExchangeRateXmlService.asmx HTTP/1.1
What toolset are you using to call this web service? I am going to assume that you haven't worked with "web services" before.
Instead of creating the XML by hand I would recommend using .net or java to create "proxy" class code against this "WSDL". You can start by googling or binging for "How to consume a web service in .net" or your language of choice.
I reserve the right to change my answer as additional details emerge.
I'm pretty new to SOAP so go easy on me. I'm trying to setup a SOAP service that accepts the following header format:
<soap:Header>
<wsse:Security>
<wsse:UsernameToken wsu:Id='SecurityToken-securityToken'>
<wsse:Username>Username</wsse:Username>
<wsse:Password>Password</wsse:Password>
<wsu:Created>Timestamp</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
The application I'm incorporating this service into is an ASP.NET 3.5 web application and I've already setup a SOAP endpoint using WCF. I've setup a basic service to make sure the WCF works and it works fine (disregarding the header). I heard that the above format follows WS-Security so I added WSHttpBinding in the web.config:
<service name="Nexternal.Service.XMLTools.VNService"
behaviorConfiguration="VNServiceBehavior">
<!--The first endpoint would be picked up from the confirg
this shows how the config can be overriden with the service host-->
<endpoint address=""
binding="wsHttpBinding"
contract="Nexternal.Service.XMLTools.IVNService"/>
</service>
I downloaded a test harness (soapUI) and pasted in a test message with the above header and it came back with a 400 Bad Request error.
...for what it's worth, I'm running Visual Studio 2008 using IIS7.
I feel like I'm going in circles so any help would be awesome. Thanks in advance.
Figured it out. I was able to customize what was generated in the WSDL using MessageContracts (http://msdn.microsoft.com/en-us/library/ms730255.aspx). This allowed me to specify the format of the header. For each node that contained child nodes I created a class to represent that node and used .NET's serializing tools (e.g. XmlElementAttribute, XmlArrayAttribute, etc.) to specify how this should be reflected in the generated WSDL. DataContract could also be used although from my understanding DataContract was just for basic formats and don't allow you to really dive into how it's formatted.
Hope this helps anyone having similar issues.
If anyone that knows more about SOAP finds a flaw please let me know. Input is greatly appreciated.
This is maybe a really simple question, but I couldn't locate an answer:
For a client I need to HOST a webservice. The client has sent me a wsdl file that the webservice should 'implement'. How do I go about that? I've generated any number of client-rpoxies but this is the other way around. I can use both ASP.NET 2.0 webservices or Windows Communication Foundation.
wsdl.exe /server.
Generates an abstract class for an XML
Web service based on the contracts.
The default is to generate client
proxy classes. When using the
/parameters option, this value is a
element that contains
"server".
You can do a similar thing with svcutil.exe for WCF- something like:
svcutil.exe thewsdl.wsdl /language:c# /out:ITheInterface.cs (I've not tested this).
Edit- John Saunders makes a good point in his answer to favour the WCF approach- I recommend this too.
Actually, you should do this with svcutil.exe, not with wsdl.exe. WSDL.EXE is part of the ASMX web service technology that Microsoft now considers to be "legacy" code, which will not have bugs fixed.
You can do plenty with that WSDL (wissd'le) file.
From doing the WS Class manually to use the Auto Generated class from wsdl.exe
let's imagine that, for your example, you have this WDSL (tooked from WebServiceX.Net)
to create a C# auto generated proxy you go to your command prompt and write:
wsdl /language:cs /protocol:soap /out:C:\myProxyScripts http://www.webservicex.net/TranslateService.asmx?wsdl
Note: inside your C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin folder you will find wsdl.exe or just do a dir /s inside your C:\Program Files\
if you want in Visual Basic, just use /language:vb or /l:vb
/language:
The language to use for the generated proxy class. Choose from 'CS',
'VB', 'JS', 'VJS', 'CPP' or provide a fully-qualified name for a class implementing System.CodeDom.Compiler.CodeDomProvider.
The default
language is 'CS' (CSharp). Short form is '/l:'.
This command will put inside your C:\myProxyScripts the auto generated proxy.
if your using the WSDL file in your computer, just change the URL to your full path, for example
wsdl /language:cs /protocol:soap /out:C:\myProxyScripts C:\myProxyScripts\myWsdlFile.wsdl
Note: your Generated proxy will be called the Service Name, the one you have specified, in our example, as:
<wsdl:service name="TranslateService">
I hope this helps you, understand the WSDL, the Auto Generated Proxies and that you can manage now everything in your end to fulfill your client wishes.
You can use the wsdl utility from microsoft to generate the server interfaces and implement them
Here is a short description of the WSDL utility.
wsdl.exe -
Utility to generate code for xml web service clients and xml web
services
using ASP.NET from WSDL contract files, XSD schemas and .discomap
discovery documents. This tool can be used in conjunction with disco.exe.
I'm developing a web application (ASP.NET 3.5) that will consume a number of web services. I have created a separate dll-project for each web service: these projects contains the service reference and client code.
However, the calling website MUST have the <system.serviceModel> information (the <bindings> and <client> nodes) in it's web.config, even though this information is also in the dll's app.config file! I have tried copying the serviceclass.dll.config over to the bin directory of the website, but this didn't help.
Is there any way to centralize the configuration of a WCF client?
I've only limited WCF experience, all with BasicHTTP bindings. But I'm allergic to WCF's xml files and have managed to avoid them thus far. I don't recomend this generally but I put the configuration details in my apps existing configuration store and then apply them programatically. E.g. With a Web service proxy I use the constructor for the Client that takes 'bindings'and 'endpoint' and programatically apply the settings to the bindings & endpoint.
A more elegent solution appears to be descibed here: Reading WCF Configuration from a Custom Location, but I haven't tried it yet.
From my experience, library projects never read app.config.
So you can really delete the file because it is not used. The library's host configuration is read instead, so that is the only place the endpoint and binding configuration should be.
It's possible to forgo xml config and build up the Binding and Endpoint classes associated with the service in the constructor or a custom "Service Factory". iDesign has some good information on this:
http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11
(See In Proc Factory)
In their approach, you set attributes on your services to specify at a high level how they should work (ie [Internet], [Intranet], [BusinessToBusiness]), and the service factory configures the service according to best practices for each scenario. Their book describes building this sort of service:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
If you just want to share configuration XML config, maybe use the configSource attribute to specify a path for configuration: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx
Remember that a configuration file is is read by an executable that has an entry point. A library dll does not have an entry point so it is not the assembly that will read it. The executing assembly must have a configuration file to read.
If you would like to centralize your web configs then I would suggest you look into nesting them in IIS with virtual directories. This will allow you to use the configuration inheritance to centralize whatever you need.
There are 2 options.
Option 1. Working with channels.
If you are working with channels directly, .NET 4.0 and .NET 4.5 has the ConfigurationChannelFactory. The example on MSDN looks like this:
ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
fileMap.ExeConfigFilename = "Test.config";
Configuration newConfiguration = ConfigurationManager.OpenMappedExeConfiguration(
fileMap,
ConfigurationUserLevel.None);
ConfigurationChannelFactory<ICalculatorChannel> factory1 =
new ConfigurationChannelFactory<ICalculatorChannel>(
"endpoint1",
newConfiguration,
new EndpointAddress("http://localhost:8000/servicemodelsamples/service"));
ICalculatorChannel client1 = factory1.CreateChannel();
As pointed out by Langdon, you can use the endpoint address from the configuration file by simply passing in null, like this:
var factory1 = new ConfigurationChannelFactory<ICalculatorChannel>(
"endpoint1",
newConfiguration,
null);
ICalculatorChannel client1 = factory1.CreateChannel();
This is discussed in the MSDN documentation.
Option 2. Working with proxies.
If you're working with code-generated proxies, you can read the config file and load a ServiceModelSectionGroup. There is a bit more work involved than simply using the ConfigurationChannelFactory but at least you can continue using the generated proxy (that under the hood uses a ChannelFactory and manages the IChannelFactory for you.
Pablo Cibraro shows a nice example of this here: Getting WCF Bindings and Behaviors from any config source
First of all class libraries (DLLs) do not have their own configuration, however they can read the configuration of their host (Web/Executable etc.). That being said, I still maintain an app.config file on the library projects as a template and easy reference.
As far as the service configuration itself is concerned, WCF configuration can make somebody easily pull their hair out. It is an over-engineered over-complicated piece. The goal of your applications should be to depend least on the configuration, while maintaining flexibility of deployment scenarios your product is going to come across.