I want to create a WCF service that may be accessed only on localhost.
I couldn't find any reference for that, is that possible?
All the posts I had found talked about this scenario as a bug, well I'd like it as a feature.
Any ideas?
If you're flexible on protocols, you could use a netNamedPipeBinding hosted in a Windows service.
You can configure the binding for the web site it is attached to and change it to localhost, rather than *. If you are hosting other services that need external access you can always create a new web site on a different port, such as localhost:8000.
A WCF service should be agnostic about how it's hosted or accessed.
Whatever's hosting the service, on the other hand, determines how the service can be accessed.
As Mike Goodwin suggested, having your host only allow netNamedPipeBinding will restrict the service to only be accessible via the machine that the host is running on.
Here's an article on the various transport protocols, including named pipes.
Here's a pretty in depth article on hosting WCF services.
Related
I've recently discovered Azure Relay and it seems very powerful. I have a basic project using it now to expose a WCF Windows Service. I've read in the documentation about how it can be used to expose RESTful services, but I'm having trouble understanding if it can be used to expose a SOAP web service. I can't seem to find any examples of that and the closest I can is this post about exposing the WSDL. I have an extremely simple SOAP web service with a single method that takes in 5 strings as arguments. I know WCF Services can be hosted in IIS but my client's requirement is that no firewall ports are opened so here's my actual question:
Is there a way to use a Relay to expose an internal IIS WebService publicly? Is there another method I might have overlooked to get around opening a port in the firewall?
I would be very open to exposing the service I have or rewriting it completely since it's so simple, I'm just not sure what my options are.
You could try to re-implement the service as RESTful service or as a Web API and then use Azure's API Management to expose it to the outer world.
Hope it helps!
I am trying to create a chat application in WCF.
I've created the client and the service on a localhost using httpBinding,
this is the service endpoint:
http://localhost:9999/ProductService
Now, I really don't know how to make the program run 'globaly' and not on a localhost.
Is there anyway to host the server on my pc? or run the application serverless using p2p communications?
Thanks anyway for your Time
You can set up at publicly accessible web server on your own computer, but it's definitely not recommended for any production purposes, unless you have a good understanding of this and have a internet-connection that allows for it, both technically and legally.
You should probably get external web hosting for this instead.
But if you really want to do this, you can install IIS to host the service.
As a side note, I don't think WCF is the optimal route to take for this anymore. Maybee you should check out SignalR and/or WebSockets instead. And ASP.NET Core WebAPI. It's not really anything wrong with WCF, but for new projects I wouldn't recommend it.
I’m currently working on a web service application project which will run in IIS7 on Windows Server 2008. The web services will be invoked from various clients, from outside the server but also from other components from within the same server. (Other web services and windows services)
My view is that the purpose of web services is to expose functionality so that external clients can invoke it. I really don’t see much sense in a web service invoking another web service on the same server or a windows service invoking a web service on the same server. Please correct me if I’m wrong?
I’ve started looking into WCF, but I’m quite confused.
Would it be more appropriate to do the following?
Instead of a web service project implement a WCF service.
Expose two endpoints:
1)One, which will be exposed using traditional web service binding which will be invoked from external clients.
2)Another endpoint so that internal services, (other web services or windows services) can invoke them, supposingly more effectively, surpassing a security layer as these are aplications already running on the server.
Would my approach be correct or am I overcomplicating things?
Any suggestions or links which could point me in the right direction appreciated.
Thanks
A web service calling another web service?
If they have different responsibilities I think it's a good idea to separate them. You get better separation on concerns (easier to share with other projects / code bases), easier maintainability and independent deployability.
I would go with WCF and have two different endpoints for the different consumers, and for example use net.pipe for communication on the same server (if the client supports it) and http for external clients.
I think WCF gives you more power and flexibility that old xml web services, and the configuration part is really good.
BasicHttpBinding will give you most interoperability with external clients.
named pipes will give you the best efficiency when both services are hosted on same machine.
BasicHttpBinding is like old asmx & XML web services.
Exposing both endpoints is AOK!
One service calling another service is NOT unusual.
Hosting multiple services on same machine is common. In the enterprise, running multiple instances of SQL-Server is commonplace. Of course it depends on hardware, services & response times.
Does WCF self hosting, still uses IIS or some Virtual Server based on IIS.
Eg: After coding a very basic WCF host, it s possible to invoke an endpoint such as
http://localhost:9090/foo.svc
For example: invoking a WCF host via TCP, does that use IIS internally?
I m trying to avoid IIS due to another app i m using, which doenst work with IIS Threads. That s why asking. so i d like to manage my own AppDomain and threadpool rather than IIS.
Any recommendation?
Can i seperate hosting of WCF from IIS?
When you self-host, you are using not a shred of IIS at all. You don't need IIS on that machine - nothing.
WCF self-hosting will require the http.sys driver for its http-based communication - but that's all there is. There is absolutely no trace of IIS needed - none, zip, nada.
Self-hosting WCF also allows you to pick your own service addresses and use whatever suits your needs - there's no virtual directory and no *.svc file to be dealt with.
It depends on the bindings. if you do a BasicHttpBinding, then all the communication will be over HTTP.
As for hosting WCF, there is the test server that comes with Visual Studio that you can use (it runs as a service. It's called WcfSvcHost.exe), but I wouldn't recommend it for production. If you are just testing, then you could just launch the WCF in the Visual Studio debugger and use its address all you want (it will be http://localhost:1234/foo.svc in that case)
If you are looking for a production hosting, you can use WCF as a SOAP endpoint, and here there is a pretty good article over at The Code Project that talks about creating a service for self hosting
We have a 2.0 Web Service proxy generated for a WCF Service. This service required Basic authentication, but periodically we experience problems that the proxy cannot connect to the Server.
The application is installed on a cluster and referencing a cluster that holds the WCF Service.
Anyone experience this problem already?
Could be that the service is only installed / working on one server in the cluster. Therefore, sometimes it works and sometimes it does not, depending on which machine you hit.
Apparantly it has to do with the setup of the environment. All the machines are virtual and the errors occurs depending on the host they are running on. I also was able to reproduce it with the WCF Proxy as well by switching on/off VM's.
thanks for the answers
You may want to consider deploying an ASMX service backed by the WCF service class. This gives you a classic XML webservices facade to work with.