Communication between two Applications

  • Thread starter Thread starter Jörg Krause
  • Start date Start date
J

Jörg Krause

Hi,

I've a webservice app, which is called from the internet.
Internally I have a application which holds a stateful connection
to a database. The webservice should use the (one and only)
connection the other app has established to the DB server.

How can these two apps (webservice and connector) communicate
together? I think remoting is possible but both apps run on the
same machine. I think Enterprise Services is good, but i don't
need the huge rest of the enterprise stuff.

Are there any other ways two .NET apps can establish a simple,
reliable and fast channel, where one app is permantly running
(like a service) and the other is started/stopped on request
(like ASP.NET pages)?

Joerg
 
Remoting would be the easiest thing to do, and it'll be quite fast. The
"service" can host the objects, so your webservice just connects to the
service when needed.
-mike
MVP
 
Thanks for your answer.

For my understanding Remoting using tcp with binary formatter will
go through the protocol stack. This may be fast for most apps but
not such efficient as an "in memory" access.

Is there any thing in .NET like public semaphores using the reserved
memory to exchange values? It is possible to program such a feature,
some kind of "ultra light enterprise services"? Anybody interested
in this? Can anybody point in the right direction?

-Joerg
 
This link:
http://www.gotdotnet.com/Community/...mpleGuid=43a1ef11-c57c-45c7-a67f-ed68978f3d6d

includes source code for a custom channel for .NET remoting, utilizing named
pipes.
If you were so inclined you could modify it to used shared memory?

Or you could purchase a custom channel.
This company:
http://www.genuinechannels.com/Content.aspx?type=1

claims 10-20% faster perf for an in-memory channel rather than using the TCP
channel.
What!?!??! only 10% improvement. I suspect that most of the cost is not in
the network stack - it is in the serialization.

-D
 
As Dino mentioned, you can go shared memory or named pipes, but it might not
be worth the extra work required (if a problem arises, support will be
less).
-mike
MVP
 
Dino Chiesa said:
This link:
http://www.gotdotnet.com/Community/...mpleGuid=43a1ef11-c57c-45c7-a67f-ed68978f3d6d

includes source code for a custom channel for .NET remoting, utilizing named
pipes.
If you were so inclined you could modify it to used shared memory?

Or you could purchase a custom channel.
This company:
http://www.genuinechannels.com/Content.aspx?type=1

claims 10-20% faster perf for an in-memory channel rather than using the TCP
channel.
What!?!??! only 10% improvement. I suspect that most of the cost is not in
the network stack - it is in the serialization.

-D
Click to expand...
[...]
Thanks for the answers. Yes, I agree with you that 10% is not worth
the effort. But if two native .NET apps talking together is there
still a serialization necessary? I think about such a thing like the
Application or Cache classes used in ASP.NET to store variables in
memory and interchange between sessions, but the target here is a
WinForms app.
For the Application object the IIS controls the shared memory. I think
this is very efficient and reliable. For my app I've a webservice
running so the IIS must be present. This gaves me a new idea: Is there
a (theoretical) way to access the Application object from a WinForms
application, may be via WMI or another technique accessing the IIS and
look into a running web?

Joerg
 
Thanks for the answers. Yes, I agree with you that 10% is not worth
the effort. But if two native .NET apps talking together is there
still a serialization necessary?
Click to expand...

If the 2 apps are in different processes, then yes, there is some sort of
serialization required. Somehow the bytes in memory for app 1 have to be
copied and transported, and become bytes in memory accessible to app 2.
this is (partly) the process of serialization.
I think about such a thing like the
Application or Cache classes used in ASP.NET to store variables in
memory and interchange between sessions, but the target here is a
WinForms app.
Click to expand...

Yes, absolutely, but the session object is being shared among threads in the
same process, not among different apps. If you have session state scale
out, then the session is persisted either to a memory buffer or to SQL
Server. And when this happens, you guessed it, you need to serialize the
session object.
For the Application object the IIS controls the shared memory. I think
this is very efficient and reliable. For my app I've a webservice
running so the IIS must be present. This gaves me a new idea: Is there
a (theoretical) way to access the Application object from a WinForms
application, may be via WMI or another technique accessing the IIS and
look into a running web?
Click to expand...

Just now I had to revist your original post to try to understand the basic
requirement. you said you want to connect a webservice to a second
application. Why is the webservice distinct from the other application -the
one that holds the connection to the database? Why not allow IIS to host
the webservice, and your other logic?

Is this second application a WinForms app? Possibly your goals would be met
by integrating the WinForms piece with ASP.NET? Have you considered
hosting ASP.NET within the WinForms app? Here is a diary entry discussing
the possibility. http://www.iunknown.com/000099.html

This may be the simplest way to do it - there is no remoting or remote
communication whatsoever. However, I would caution you that hosting ASP.NET
within a client-side app is not an approach that is suitable for typical
server use!

-D
 
If you have underlying database you are better off with database solution.
You can use also messaging - MSMQ or any another product for asynchronous
messaging.

If you have already web service in place why you can't connect to it from
WinForms application?

Just my 0.02

Alex
 
--
Dino Chiesa said:
[...]

Just now I had to revist your original post to try to understand the basic
requirement. you said you want to connect a webservice to a second
application. Why is the webservice distinct from the other application -the
one that holds the connection to the database? Why not allow IIS to host
the webservice, and your other logic?
Click to expand...

The whole application is a bit more complicated then described before. We
have a few systems controlling some machines in a production environment.
Each system runs a WinForm app which builds the user interface for the
worker at the particular machine. Each system reports changes of machine
state
via Remoting to one central system. Separatly from that system another
machine exists running the webservice. Various clients (Win and WebForm)
from
within the company management can access the webservice and retrieve the
state of the production line.
Actually each request to the webservice creates a request via remoting to
the central system (which is indeed a sql server). The state of the system
does not change very often, but the webservice is called frequently. Now
we using remoting to pull the data from central system frequently.
What I want is the way back: The central system should inform the webservice
computer via Remoting that some data changed. This is simple by setting up
a remoting server on the webservice machine.
The problem initially described occurs here: How can the webservice retrieve
the data from the remoting server application on the same machine in the
most efficient way? This was the reason I've asked for, because both apps
are running the same time and the amount of data is not very high, using
MSDE or Files to store the data seems to be not necessary, a bit of memory,
a few hundred bytes, is enough.
Is this second application a WinForms app? Possibly your goals would be met
by integrating the WinForms piece with ASP.NET? Have you considered
hosting ASP.NET within the WinForms app? Here is a diary entry discussing
the possibility. http://www.iunknown.com/000099.html
Click to expand...

This is very interesting, but we lost all the advantages of IIS?
This may be the simplest way to do it - there is no remoting or remote
communication whatsoever. However, I would caution you that hosting ASP.NET
within a client-side app is not an approach that is suitable for typical
server use!

Yes.

-D
Click to expand...

Thanks for your ideas. During further investigation I found Semaphores,
which
are not really implemented in the CLR, but native Win32 APIs can be used.
I hope I can implement a small project...

Joerg
 
The whole application is a bit more complicated then described before.
Click to expand...

Ahh, yes, isn't that always the case?
We
have a few systems controlling some machines in a production environment.
Each system runs a WinForm app which builds the user interface for the
worker at the particular machine. Each system reports changes of machine
state
via Remoting to one central system. Separatly from that system another
machine exists running the webservice. Various clients (Win and WebForm)
from
within the company management can access the webservice and retrieve the
state of the production line.

Actually each request to the webservice creates a request via remoting to
the central system (which is indeed a sql server). The state of the system
does not change very often, but the webservice is called frequently. Now
we using remoting to pull the data from central system frequently.
What I want is the way back: The central system should inform the webservice
computer via Remoting that some data changed. This is simple by setting up
a remoting server on the webservice machine.
The problem initially described occurs here: How can the webservice retrieve
the data from the remoting server application on the same machine in the
most efficient way? This was the reason I've asked for, because both apps
are running the same time and the amount of data is not very high, using
MSDE or Files to store the data seems to be not necessary, a bit of memory,
a few hundred bytes, is enough.
Click to expand...

Ahh, ok, then. Two new suggestions:
1. Why not use webservices to communicate from the "central system" (Call
it C) back to the webservices system (call it W). C can call W via a
separate webmethod. This webmethod can be protected so that only C can
invoke it (public calls would be disallowed). In this case, you would
eliminate the condition of "2 apps" that need to communicate on W. Instead
there is only one app, exposing webservices - some methods are called from
external clients, and some methods are called from the "remoting server".
The remoting server needs to be compiled with a proxy generated from the
ASMX WSDL for the webservice.


2. If you really want to use remoting to communicate between C and W, have
you considered hosting a remoting server within the ASPX app? A single
application would act as both a Remoting server and a webservices server.
IIS hosts it.
Here's a blog entry about the web.config incantations you need to take this
approach: http://weblogs.asp.net/mnissen/story/9160.aspx [ You can also
allow the same application to act as a Remoting Client, although that does
not seem to be required in your case. ] The asmx and remoting interfaces
can call into the same objects on the webservices server. You'd want to
synchronize access to these objects to avoid overwrites or dirty reads.

-Dino
 
Back
Top