1

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

Rauland
  • 2,944
  • 5
  • 34
  • 44
  • 1
    Is it not possible to use the business layer of the other web service directly instead on the server? – Dreamwalker Feb 27 '13 at 09:07
  • No, I'd rather the service functioned as an aplication on it's own as it requires initializing , stores in memory a set of configuration paramters which is used through out. If other clients, directly invoked the business layer they would have to deal with all of this on their own. Also any updates would require them updating there references, reinstalling etc. – Rauland Feb 27 '13 at 09:16
  • 1
    Use a TCP endpoint then I think on local host only with no security would be the best way I think. Not sure you can get better performance than doing that. see link for stats http://stackoverflow.com/questions/4519963/wcf-how-much-faster-is-tcp-than-http – Dreamwalker Feb 27 '13 at 09:35
  • 1
    Use named pipes NOT "TCP with no security" when service & client are on the same machine. – Steven Licht Feb 28 '13 at 13:44

2 Answers2

1

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.

Jocke
  • 2,189
  • 1
  • 16
  • 24
  • I'm wondering if this is a common scenario for a server, where one wcf service has more than one endpoint depending on the consumer (one for "BasicHttpBinding" and another for "net.pipe".), so a windows service or another wcf service, would call the "net.pipe" and external clients the "BasicHttpBinding" one. – Rauland Feb 27 '13 at 12:24
  • 1
    I don't have any hard data to back it up, but I would say yes it's common. I use it myself. – Jocke Feb 27 '13 at 14:13
1

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.

Steven Licht
  • 760
  • 4
  • 5