1

I'm developing a webservice that will, when called, notify another program via a tcp connection. My problem is where to store the open tcp connection. The way I understand web services, they start and end with each HTTP Request, with no room for application wide variables, like the open tcp connection.

Please correct me if I'm wrong.

Specifically, in what part of the asmx file, or outside of it, should I place the code for listening for incoming tcp traffic?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
lowerkey
  • 8,105
  • 17
  • 68
  • 102
  • 2
    Are you aware that ASMX is a legacy technology, and should not be used for new development? – John Saunders Jan 29 '12 at 15:49
  • I did not know that. I'm using Visual Studio 2008, because a MS Rep handed it out during class one day. The web services are still relatively small, what else can I use instead? – lowerkey Jan 29 '12 at 16:28
  • Also, do you have references? – lowerkey Jan 29 '12 at 16:31
  • WCF should be used for new development. See the reference in http://johnwsaunders3.wordpress.com/2009/07/03/microsoft-says-asmx-web-services-are-a-%E2%80%9Clegacy-technology%E2%80%9D/ – John Saunders Jan 29 '12 at 16:37
  • @JohnSaunders Your reference refers back to you, but since you cite microsoft in it, do the below answers apply to WCF? – lowerkey Jan 29 '12 at 16:51
  • The reference (my blog post) shows you where Microsoft says ASMX is a legacy technology. And, yes, you can do similar things with WCF. – John Saunders Jan 29 '12 at 16:52
  • @JohnSaunders is right, ASMX is legacy. WCF is better and more flexible for new work. My suggestion with a static member works equally well for WCF. – Anders Abel Jan 29 '12 at 18:08

3 Answers3

2

Application events in Global.asax should fire for a web service hosted as an application in IIS. You can use these. Keep in mind that they will fire even if a web page and not the web service is accessed in the same application.

Stilgar
  • 22,354
  • 14
  • 64
  • 101
1

You can place the tcp connection as a static member of the service class and make a static constructor that handles the instantiation.

This will create the tcp connection before the first access of the web service is handled and then persist the connection as long as the hosting process is running. The only drawback with that approach is that the tcp connection is process wide. If you host two instances of the web service within the same process (quite unlikely) they will share the same tcp connection.

Anders Abel
  • 67,989
  • 17
  • 150
  • 217
  • Having one tcp connection for all instances of the web services is exactly what I want. Thanks for the tip! – lowerkey Jan 29 '12 at 16:29
1

Fortunately for you, you are wrong.

Application-wide events do fire plus you have the access to all asp.net containers, the Application container for application-level variables, the Session container for session-level variables (if the client side supports cookies, the session id could even be passed in a cookie) and the Items container for request-level variables.

However, whether or not this helps you to store an additional tcp listener (if I understand correcly) is another story, not obvious one.

Wiktor Zychla
  • 47,367
  • 6
  • 74
  • 106