I'm very confused by this.
I have a SOAP client, talking to a server somewhere. I'm using WCF with a wsHttpBinding to talk to it.
Inside my app.config, the endpoint address is set as
<endpoint address="https://something.example.com/someService"
Since this is an https address and I'm using a transport binding, everything is happy.
However, inside the provided WSDL for this service, some of the actions are specified like:
<soap:operation soapAction="http://something.example.com/someService/someAction" style="document" />
Note how the action does not use HTTPS.
What is the deal with this? Can you mix and match transports inside one service? Won't this cause problems? How could you even talk to a service like this? wouldn't my client application have to use different endpoint configurations based on whether the action has HTTPS on it or not?
Related
suppose i have developed a WCF service with one mex endpoint. now i like to know how can i secure the mex endpoint means that if anyone know my mex endpoint address then that user may not be able to add my mex endpoint address from their VS IDE to create proxy. if user try to do so then windows auth login dialog comes.
now the question is how then any out side user will be able to call my wcf service. i will distribute my service dll or proxy class related *.cs files or WSDL. so user can add that dll or add those proxy related .cs file or add wsdl to their project to create proxy just to call & consume my service. i am not advance developer so i am not being able to understand how to develop this kind of secure wcf service where user can not add my mex endpoint.
so just guide me with little wcf sample code & config example from where i can understand what i need to to meet my requirement. thanks
This topic looks helpful
https://msdn.microsoft.com/en-us/library/aa395212%28v=vs.110%29.aspx
Initially, one would think one would just change the HTTP to HTTPS but according to the article apparently you lose some degree of freedom in configuration
If you use the mexHttpsBinding your metadata endpoint will be secure, but there is no way to modify the binding settings.
I have small question,
If I host NetTcpbinding WCF service in IIS 7.0 and I want to invoke this service from Client application, then what format this will be used fo communication..??
Is there any rule saying that, all NetTcpbinding should not host on IIS instead they have to host on Console application or windows service..??
When extactly I want to go for TcpNet binding..??
Suppose, I have two endpoints one for WsHttpbinding and other one is NetTcpbinding and deploy Service in IIS then If I want to use NetTcp endpoint from Client application then how..?? Is this correct way to do...?? in this scenario...
Thanks,
Sukesh.
NetTcpBinding Class info:
http://msdn.microsoft.com/en-us/library/ms576421.aspx
Quoted from the remarks:
The NetTcpBinding generates a run-time communication stack by default, which uses transport security, TCP for message delivery, and a binary message encoding. This binding is an appropriate Windows Communication Foundation (WCF) system-provided choice for communicating over an Intranet.
Quote indicates that a Client-Server connection is established via TCP and this is used to send the SOAP Message encoded in binary.
2.
No. There is even this nice blog post on how to do it:
http://blogs.msdn.com/b/santhoshonline/archive/2010/07/01/howto-nettcpbinding-on-iis-and-things-to-remember.aspx
3.
Back to the class info:
More generally, the HTTP system-provided bindings such as WSHttpBinding and BasicHttpBinding are configured to turn things on by default, whereas the NetTcpBinding binding turns things off by default so that you have to opt-in to get support, for example, for one of the WS-* specifications. This means that the default configuration for TCP is faster at exchanging messages between endpoints than that configured for the HTTP bindings by default.
This means that this binding doesn't do all the higher level processing that basicHttpBinding and WSHttpBinding do due to the additional protocol layers expected (http layer and WS-* spec layer). So this is a higher performance binding configuration giving you a faster turn around time in your service message replies at the cost of losing your http layer (clients can no longer just HTTP POST soap envelopes to your service).
4.
I would set up two separate service endpoints(one TCP and one WSHttp) that implement the same interface. Then you can set up two client config items on the client end that again use different binding configuration but call to the same interface. Then you can just load either.
<client>
<endpoint name="WSEndpoint" address="http://address/WSEndpoint.svc" binding="WSHttpBinding" contract="Your.Contract.Namespace"/>
<endpoint name="TCPEndpoint" address="http://address/TCPEndpoint.svc" binding="NetTcpBinding" contract="Your.Contract.Namespace"/>
</client>
I'm using IE8 and can't connect to my WCF service using net.tcp. I'm able to access the same service with http binding just fine. I got two binding enabled in app.config (net.tcp, http). Can anyone tell me if there is a settings that I need to set/play with for viewing service using net.tcp in IE.
You cannot connect to a WCF service using the netTcpBinding through IE.
What you need is a "real" WCF client app, or something like WCF Test Client which is shipped with WCF in the box - just find it and start using it!
Make sure you have a HTTP base address, for your service and a mexTcpBinding endpoint.
We host a WCF webservice on Windows Server 2003. This server only has 2 internal IP's. We want to expose the service externally. This is done through the firewall that maps an external IP to the service.
So, I would need to modify the service to display that external IP for the internal links. This is not an issue since it should only be used externally.
Changing the Host Header value in IIS gives a 'Bad Request (Invalid Hostname)' response from IIS. I also added an 'address' value to the endpoint entry in the web.config ... but it sill just points to the internal machine name. Any ideas?
edit: I can verify that IIS7 has the exact same behaviour. Address didn't work. Different hostname gave Invalid Hostname error. Is there seriously no way to present a different (fictive) IP? :/
edit2:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicAnonymous">
<security mode="None"/>
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="Extended">
<serviceMetadata httpGetEnabled="true"/>
<dataContractSerializer maxItemsInObjectGraph="2147483646"/>
</behavior>
</serviceBehaviors>
</behaviors>
<diagnostics>
<messageLogging logEntireMessage="true" logMalformedMessages="false" logMessagesAtServiceLevel="false" logMessagesAtTransportLevel="true" maxMessagesToLog="3000"/>
</diagnostics>
<services>
<service behaviorConfiguration="Extended" name="AnCWCFWebService.ProductInfoProvider">
<endpoint address="" binding="basicHttpBinding" name="ASMX" bindingConfiguration="BasicAnonymous" contract="AnCWCFWebService.Interfaces.IProductInfoProvider"/>
</service>
</services>
</system.serviceModel>
404 BadRequest Due to IIS Configuration...
If you are receiving a 404 BadRequest error from IIS after attempting to modify host headers in IIS, this is common, but there is a fix!
Fix By Making IIS Configuration Changes
How can WCF support multiple IIS Binding specified per site?
Fix By Making WCF Code Modifications
Alternatively, the following article explains how one developer solved this issue with a combination of configuration and code:
Well, that was fun! An adventure in WCF, SSL, and Host Headers
http://geekswithblogs.net/rakker/archive/2008/07/03/123562.aspx
The article references two important links...
The first one explains how to properly set the host headers in IIS:
Configuring Server Bindings for SSL Host Headers (IIS 6.0): http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/8d9f2a8f-cd23-448c-b2c7-f4e87b9e2d2c.mspx?mfr=true
After getting host headers working, you'll find that...
"you can't have more than one host
header for IIS or wcf will break"
The solution to working around this limitation is found within this article, and there is also a comment on the GeeksWithBlogs.net article above that provides an enhanced variation:
WCF: This collection already contains
an address with scheme http
If you are still experiencing trouble, let us know in the comments below...
If the Service is Not Working...
My experience with WCF is that it is very tricky at times, especially with configuration. If one is following best practices and not doing anything non-standard, the great majority of deployment problems are the result of a botched configuration file.
In theory (not so much in practice, due to architectural differences), setting up a WCF service on IIS should be no different than setting up a typical virtual directory and corresponding application for web application or for an ASMX web service.
Therefore, I recommend that if this is the first WCF service you are exposing to the Internet, follow the same simple approach you would take when exposing your first website. Basically, create a new sample "WCF Service Application" (this is available in the Add New Project dialog, under the Web section of C# or VB).
Once you have it working, follow your deployment practices to move it into a production sandbox and test it locally. This sandbox would preferably already have some web sites or web services installed and known to be accessible from the Internet, in order to eliminate any doubt about the typical network configuration issues. If you have a sample ASMX web service that is already successfully exposed on the Internet from that server, that would be best.
Next, try testing the the ASMX and the WCF services from web browser, both locally on the server, internally on other desktops and then finally externally.
Testing URLs
We want to test accessing the standard SVC and ASMX file from the web browser in all the varieties of URL flavors that are available and relevant. The results should be similar, with summary page about he service rendering in the window. The difference will be that the ASMX web service's summary will likely allow you to execute the web methods on the service if that feature has not been disabled in the web.config file.
Compare the results of browser fetches of the following styles of URLs...
http://localhost/WcfService1/Service1.svc
http://localhost/WcfService1/Service1.asmx
http://MachineName or MachineFQN/WcfService1/Service1.svc
http://MachineName or MachineFQN/WcfService1/Service1.asmx
http://MachineLocalIP#1/WcfService1/Service1.svc
http://MachineLocalIP#1/WcfService1/Service1.asmx
http://MachineLocalIP#2/WcfService1/Service1.svc
http://MachineLocalIP#2/WcfService1/Service1.asmx
http://ExternalIP/WcfService1/Service1.svc
http://ExternalIP/WcfService1/Service1.asmx
All of these tests should return similar results.
Testing Service Methods
If you feel like it, go head and test some web methods on the ASMX web service for any of the tested URLs, from the web browser. You'll soon see that we can test ASMX web services a different way also...
Next we'll test web methods on both the WCF service and the ASMX web service by using the WcfTestClient.exe application that is found in the Visual Studio 2008 distribution (C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE).
You will need to add the services through the File->Add Service menu item, typing in the URL above for each service URL that you wish to test. Make sure to include the filename of the SVC and ASMX files. If all is well, the MEX endpoint that is enabled by the "httpGetEnabled" attribute of the <serviceMetadata/> element in the web.config file will return the data that is necessary for the utility to operate, thereby populating the tree with the inventory of our service methods like this:
From this point, it will be useful to refer to the following to resources:
WCFTestClient: http://msdn.microsoft.com/en-us/library/bb552364.aspx
What's New for WCF in Visual Studio 2008: http://msdn.microsoft.com/en-us/magazine/cc163289.aspx
Conclusion
If you make it this far, then I do not expect any other issues and you should now attempt to compare the setup of the samples to the WCF service that you are attempting to publish to the Internet, and hopefully the differences will be obvious.
Remember to treat the WCF service like an ASMX web service during you diagnostics, assuming that the web.config is known to be set up correctly.
If you are still unable to make things work, check this guide for further technical advice:
Deploying an IIS-hosted WCF service: http://msdn.microsoft.com/en-us/library/aa751792.aspx
Finally, if all else fails, just wrap your WCF service in an ASMX web service:
How to: Expose WCF service also as ASMX web-service: http://kjellsj.blogspot.com/2006/12/how-to-expose-wcf-service-also-as-asmx.html
You just need to configure your host header in the IIS so that the links in the WSDL references will use the donmain name rather local machine name.
Check out
Steps to configure IIS host header so that WCF will use domain name in WSDL references.
Why not just assign a new IP address to the server instead of messing around with hostnames? A Windows Server can have multiple IP addresses for the same NIC.
Here is an article that talks about it.
Is anybody familiar with setting up WCF-nettcp adapters for BTS?
When I create a WCF-netTcp adapter for a Receive location, I am unsure how/when BTS will open up port 808 to listen on the address URI specified. It appears to only happen if I restart the entire BizTalk application. If it closes for some reason, I do not see any way of reconfiguring and reopening the port.
Furthermore, since that is only the net.tcp binding, there is no mex endpoint exposed. I believe client applications that wish to use that exposed WCF service needs mex metadata initially. Accessing that endpoint direct from a Visual Studio project would just yield
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
If the service is defined in the current solution, try building the solution and adding the service reference again.
Cannot tell for such how to properly expose a mex endpoint to the service. the BizTalk WCF Service Publishing Wizard is confusing me; I cannot get it to reference the WCF adapter/Receive location I setup. I find no document that teaches what one ought to do for netTcp services; it is all about Http.
Funny, it took the walkthrough about publshing Net-Msmq WCF service to nudge me thinking how the WCF Service Publishing Wizard really works.
The issue is this: When I manually created the WCF-netTcp Receive location, it has its endpoint URI e.g. net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc. When selecting the option to publish just an mex endpoint in the WCF Service Publishing Wizard, it will eventually ask for the WCF Service Location, which i confused to be the actual service location. Since it would accept nothing but Http URLs, it appeared to only support Http-based WCF endpoints.
But for that textbox, one is supposed to place the Http URL that for just the mex endpoint, not the actual net.tcp WCF endpoint. That is the location in IIS where the wizard will create the necessary meta-data files. Once finished, that location, hosting a mex endpoint will inform clients of the real service located at the net.tcp endpoint.