Communication between HttpApplication that run on the same server

[[Gauthier]]

Hello,

I've a simple question:

On a server that run multiple asp.net HttpApplication, is there any way with
the asp.net framework to exchange data between different application?

I basically need to send message to a 'server wide' application from any
HttpApplication on the same server and obtain responses (wich may be simple
strings or streams for example), this 'server wide' application is also
HttpApplication.

If such feature doesn't exist, is this a place for remoting?

If this is a place for remoting did you have some hints on how I should host
the remoting server in my 'server wide' HttpApplication (keeping simple
deployment in mind)?

Thanks for any thoughts.

Gauthier

[Sherif ElMetainy]

Hello

I suggeest using xml web services. Remoting can be used too, and it can be
hosted in IIS, without the need for a separate process. Both solutions are
simple in deploymen, but the xml web service approach is simpler in
implementation.

Best regards,
Sherif

"[Gauthier]" <ms****@ifrance.com> wrote in message
news:OE**************@TK2MSFTNGP11.phx.gbl...

Hello,

I've a simple question:

On a server that run multiple asp.net HttpApplication, is there any way with the asp.net framework to exchange data between different application?

I basically need to send message to a 'server wide' application from any
HttpApplication on the same server and obtain responses (wich may be simple strings or streams for example), this 'server wide' application is also
HttpApplication.

If such feature doesn't exist, is this a place for remoting?

If this is a place for remoting did you have some hints on how I should host the remoting server in my 'server wide' HttpApplication (keeping simple
deployment in mind)?

Thanks for any thoughts.

Gauthier

[[Gauthier]]

Thanks for your reply,

I'm more interested with remoting in place of xml web service because it's a
communication between 2 process that live on the same machine and also for
performances reason.

Could you tell me how IIS can host such remote process?

A solution I was thinking about was having a System.Diagnostics.Process
launched in Global.asax.cs within the Application_Start event, a console
process with standard I/O, so I could manage to get the ProcessId in other
HttpApplication and get a reference on that process, but I'm wondering if
remoting and all stuffs that come along wouldn't be a better solution.

I'm almost concerned with request concurrency (many apps that make request
on the 'server wide' application) and I imagine this could be an issue if I
use standard I/O of the process as the sole way to communicate.

So does the solution would be a dedicated process hosted in IIS that
communicate with my httpapps with a remoting client over tcp messages would
be the good one?

Will I have to investigate on threads issues or bottleneck to implement a
such process? (that's surely why xml web service and http communication
'simplify' a lot of stuffs)

Thanks for assistance & best regards

Gauthier

"Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in message
news:eE*************@tk2msftngp13.phx.gbl...

Hello

I suggeest using xml web services. Remoting can be used too, and it can be
hosted in IIS, without the need for a separate process. Both solutions are
simple in deploymen, but the xml web service approach is simpler in
implementation.

Best regards,
Sherif

"[Gauthier]" <ms****@ifrance.com> wrote in message
news:OE**************@TK2MSFTNGP11.phx.gbl...

Hello,

I've a simple question:

On a server that run multiple asp.net HttpApplication, is there any way

with

the asp.net framework to exchange data between different application?

I basically need to send message to a 'server wide' application from any HttpApplication on the same server and obtain responses (wich may be

simple

strings or streams for example), this 'server wide' application is also
HttpApplication.

If such feature doesn't exist, is this a place for remoting?

If this is a place for remoting did you have some hints on how I should

host

the remoting server in my 'server wide' HttpApplication (keeping simple
deployment in mind)?

Thanks for any thoughts.

Gauthier

[Alvin Bruney]

Remoting is the replacement for all things DCOM. It will allow you, for
example, to push data thru one process boundary into another running process
which is what I think you are after. I'd suggest you start reading up before
you dive in because a couple issues can bite you. Look at ingo rammar's
book, it's the definitive work on remoting.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"[Gauthier]" <ms****@ifrance.com> wrote in message
news:Oy**************@TK2MSFTNGP09.phx.gbl...

Thanks for your reply,

I'm more interested with remoting in place of xml web service because it's a communication between 2 process that live on the same machine and also for
performances reason.

Could you tell me how IIS can host such remote process?

A solution I was thinking about was having a System.Diagnostics.Process
launched in Global.asax.cs within the Application_Start event, a console
process with standard I/O, so I could manage to get the ProcessId in other
HttpApplication and get a reference on that process, but I'm wondering if
remoting and all stuffs that come along wouldn't be a better solution.

I'm almost concerned with request concurrency (many apps that make request
on the 'server wide' application) and I imagine this could be an issue if I use standard I/O of the process as the sole way to communicate.

So does the solution would be a dedicated process hosted in IIS that
communicate with my httpapps with a remoting client over tcp messages would be the good one?

Will I have to investigate on threads issues or bottleneck to implement a
such process? (that's surely why xml web service and http communication
'simplify' a lot of stuffs)

Thanks for assistance & best regards

Gauthier

"Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in message
news:eE*************@tk2msftngp13.phx.gbl...

Hello

I suggeest using xml web services. Remoting can be used too, and it can be

hosted in IIS, without the need for a separate process. Both solutions are simple in deploymen, but the xml web service approach is simpler in
implementation.

Best regards,
Sherif

"[Gauthier]" <ms****@ifrance.com> wrote in message
news:OE**************@TK2MSFTNGP11.phx.gbl...

Hello,

I've a simple question:

On a server that run multiple asp.net HttpApplication, is there any way

with

the asp.net framework to exchange data between different application?

I basically need to send message to a 'server wide' application from

any

HttpApplication on the same server and obtain responses (wich may be

simple

strings or streams for example), this 'server wide' application is

also HttpApplication.

If such feature doesn't exist, is this a place for remoting?

If this is a place for remoting did you have some hints on how I should host

the remoting server in my 'server wide' HttpApplication (keeping

simple deployment in mind)?

Thanks for any thoughts.

Gauthier

[[Gauthier]]

Thanks, I've succesfully implemented a quick test and registered a
tcpchannel in my Global.asax.cs and it's work succesfully: I can call simple
methods from a remote application.

Now I've a simple question:
Is there an clean way to ensure that an httpapplication is allready started
(for my 'server wide' application), because my client applications need that
the httpapplication is started to make remote method calls, and it's fail if
the 'server wide' application is not started?

A simple solution I've think about is to make some 'activation httprequests'
on the 'server wide' application in my client applications, but that seams a
dirty solution if there is a more convinient way to autostart
httpapplications with iis or such thing.

Thanks for insight.

Gauthier

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:Os*************@tk2msftngp13.phx.gbl...

Remoting is the replacement for all things DCOM. It will allow you, for
example, to push data thru one process boundary into another running process which is what I think you are after. I'd suggest you start reading up before you dive in because a couple issues can bite you. Look at ingo rammar's
book, it's the definitive work on remoting.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"[Gauthier]" <ms****@ifrance.com> wrote in message
news:Oy**************@TK2MSFTNGP09.phx.gbl...

Thanks for your reply,

I'm more interested with remoting in place of xml web service because it's

a

communication between 2 process that live on the same machine and also for performances reason.

Could you tell me how IIS can host such remote process?

A solution I was thinking about was having a System.Diagnostics.Process
launched in Global.asax.cs within the Application_Start event, a console
process with standard I/O, so I could manage to get the ProcessId in other HttpApplication and get a reference on that process, but I'm wondering if remoting and all stuffs that come along wouldn't be a better solution.

I'm almost concerned with request concurrency (many apps that make request on the 'server wide' application) and I imagine this could be an issue if

I

use standard I/O of the process as the sole way to communicate.

So does the solution would be a dedicated process hosted in IIS that
communicate with my httpapps with a remoting client over tcp messages would

be the good one?

Will I have to investigate on threads issues or bottleneck to implement

a such process? (that's surely why xml web service and http communication
'simplify' a lot of stuffs)

Thanks for assistance & best regards

Gauthier

"Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in message
news:eE*************@tk2msftngp13.phx.gbl...

Hello

I suggeest using xml web services. Remoting can be used too, and it can be hosted in IIS, without the need for a separate process. Both solutions are simple in deploymen, but the xml web service approach is simpler in
implementation.

Best regards,
Sherif

"[Gauthier]" <ms****@ifrance.com> wrote in message
news:OE**************@TK2MSFTNGP11.phx.gbl...
> Hello,
>
> I've a simple question:
>
> On a server that run multiple asp.net HttpApplication, is there any way with
> the asp.net framework to exchange data between different

application? >
> I basically need to send message to a 'server wide' application from

any

> HttpApplication on the same server and obtain responses (wich may be
simple
> strings or streams for example), this 'server wide' application is

also > HttpApplication.
>
> If such feature doesn't exist, is this a place for remoting?
>
> If this is a place for remoting did you have some hints on how I should host
> the remoting server in my 'server wide' HttpApplication (keeping simple > deployment in mind)?
>
> Thanks for any thoughts.
>
> Gauthier
>
>

[Alvin Bruney]

you don't need to explicitly check for it. just make the call. the
application object and everthing related to it will either honor the request
if it is running or the runtime will first create and run the application,
initializing all the relevant objects before honoring the call.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"[Gauthier]" <ms****@ifrance.com> wrote in message
news:eZ*************@tk2msftngp13.phx.gbl...

Thanks, I've succesfully implemented a quick test and registered a
tcpchannel in my Global.asax.cs and it's work succesfully: I can call simple methods from a remote application.

Now I've a simple question:
Is there an clean way to ensure that an httpapplication is allready started (for my 'server wide' application), because my client applications need that the httpapplication is started to make remote method calls, and it's fail if the 'server wide' application is not started?

A simple solution I've think about is to make some 'activation httprequests' on the 'server wide' application in my client applications, but that seams a dirty solution if there is a more convinient way to autostart
httpapplications with iis or such thing.

Thanks for insight.

Gauthier

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:Os*************@tk2msftngp13.phx.gbl...

Remoting is the replacement for all things DCOM. It will allow you, for
example, to push data thru one process boundary into another running process

which is what I think you are after. I'd suggest you start reading up

before

you dive in because a couple issues can bite you. Look at ingo rammar's
book, it's the definitive work on remoting.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"[Gauthier]" <ms****@ifrance.com> wrote in message
news:Oy**************@TK2MSFTNGP09.phx.gbl...

Thanks for your reply,

I'm more interested with remoting in place of xml web service because it's

a

communication between 2 process that live on the same machine and also for performances reason.

Could you tell me how IIS can host such remote process?

A solution I was thinking about was having a System.Diagnostics.Process launched in Global.asax.cs within the Application_Start event, a console process with standard I/O, so I could manage to get the ProcessId in other HttpApplication and get a reference on that process, but I'm wondering if remoting and all stuffs that come along wouldn't be a better solution.

I'm almost concerned with request concurrency (many apps that make request on the 'server wide' application) and I imagine this could be an issue if

I

use standard I/O of the process as the sole way to communicate.

So does the solution would be a dedicated process hosted in IIS that
communicate with my httpapps with a remoting client over tcp messages

would

be the good one?

Will I have to investigate on threads issues or bottleneck to implement a such process? (that's surely why xml web service and http

communication 'simplify' a lot of stuffs)

Thanks for assistance & best regards

Gauthier

"Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in message news:eE*************@tk2msftngp13.phx.gbl...
> Hello
>
> I suggeest using xml web services. Remoting can be used too, and it

can

be

> hosted in IIS, without the need for a separate process. Both solutions are

> simple in deploymen, but the xml web service approach is simpler in
> implementation.
>
> Best regards,
> Sherif
>
> "[Gauthier]" <ms****@ifrance.com> wrote in message
> news:OE**************@TK2MSFTNGP11.phx.gbl...
> > Hello,
> >
> > I've a simple question:
> >
> > On a server that run multiple asp.net HttpApplication, is there

any way

> with
> > the asp.net framework to exchange data between different application? > >
> > I basically need to send message to a 'server wide' application

from any

> > HttpApplication on the same server and obtain responses (wich may

be > simple
> > strings or streams for example), this 'server wide' application is

also

> > HttpApplication.
> >
> > If such feature doesn't exist, is this a place for remoting?
> >
> > If this is a place for remoting did you have some hints on how I

should

> host
> > the remoting server in my 'server wide' HttpApplication (keeping

simple

> > deployment in mind)?
> >
> > Thanks for any thoughts.
> >
> > Gauthier
> >
> >
>
>

[[Gauthier]]

Hello,

I've missexplained my problem here:

My problem is that my 'server wide' HttpApplication is not allready started
in some case (for exemple just after saving the web.config of the
application).

Since I initialize my Channel in the Application_Start event, it's ok if the
application is allready started (for exemple just after a web request on
this application was made).

But i'm getting SocketException with the following message: 'No connection
could be made because the target machine actively refused it' when the
application is not allready started.

So the solution would be:
1: find a way to start the application when iis service is starting and
expecting that the application is not recycled is no request are made on it
after a period of time (is there such behavior in the asp.net framework?)

2: find a way to check that the channel exist (the 'server wide' application
is allready started) in my client remotefacade.

I've allready think about a possible implementation of the second solution
but the primmer seems simpler if it's possible and I don't know wether it is
or not.

Anyway I have to make such test (the second solution) to ensure that the
'server wide' application has registered the channel, for the sake of
robustness.

Thanks

Gauthier

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:#K**************@TK2MSFTNGP12.phx.gbl...

you don't need to explicitly check for it. just make the call. the
application object and everthing related to it will either honor the request if it is running or the runtime will first create and run the application,
initializing all the relevant objects before honoring the call.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"[Gauthier]" <ms****@ifrance.com> wrote in message
news:eZ*************@tk2msftngp13.phx.gbl...

Thanks, I've succesfully implemented a quick test and registered a
tcpchannel in my Global.asax.cs and it's work succesfully: I can call simple

methods from a remote application.

Now I've a simple question:
Is there an clean way to ensure that an httpapplication is allready

started

(for my 'server wide' application), because my client applications need

that

the httpapplication is started to make remote method calls, and it's fail if

the 'server wide' application is not started?

A simple solution I've think about is to make some 'activation httprequests'

on the 'server wide' application in my client applications, but that seams a

dirty solution if there is a more convinient way to autostart
httpapplications with iis or such thing.

Thanks for insight.

Gauthier

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote

in message news:Os*************@tk2msftngp13.phx.gbl...

Remoting is the replacement for all things DCOM. It will allow you, for example, to push data thru one process boundary into another running

process

which is what I think you are after. I'd suggest you start reading up

before

you dive in because a couple issues can bite you. Look at ingo rammar's book, it's the definitive work on remoting.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"[Gauthier]" <ms****@ifrance.com> wrote in message
news:Oy**************@TK2MSFTNGP09.phx.gbl...
> Thanks for your reply,
>
> I'm more interested with remoting in place of xml web service because

it's

a
> communication between 2 process that live on the same machine and

also for

> performances reason.
>
> Could you tell me how IIS can host such remote process?
>
> A solution I was thinking about was having a System.Diagnostics.Process > launched in Global.asax.cs within the Application_Start event, a console > process with standard I/O, so I could manage to get the ProcessId in

other

> HttpApplication and get a reference on that process, but I'm

wondering if

> remoting and all stuffs that come along wouldn't be a better

solution. >
> I'm almost concerned with request concurrency (many apps that make

request

> on the 'server wide' application) and I imagine this could be an issue if

I
> use standard I/O of the process as the sole way to communicate.
>
> So does the solution would be a dedicated process hosted in IIS that
> communicate with my httpapps with a remoting client over tcp

messages would
> be the good one?
>
> Will I have to investigate on threads issues or bottleneck to

implement

a

> such process? (that's surely why xml web service and http

communication > 'simplify' a lot of stuffs)
>
> Thanks for assistance & best regards
>
> Gauthier
>
> "Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in message > news:eE*************@tk2msftngp13.phx.gbl...
> > Hello
> >
> > I suggeest using xml web services. Remoting can be used too, and it can

be
> > hosted in IIS, without the need for a separate process. Both solutions are
> > simple in deploymen, but the xml web service approach is simpler

in > > implementation.
> >
> > Best regards,
> > Sherif
> >
> > "[Gauthier]" <ms****@ifrance.com> wrote in message
> > news:OE**************@TK2MSFTNGP11.phx.gbl...
> > > Hello,
> > >
> > > I've a simple question:
> > >
> > > On a server that run multiple asp.net HttpApplication, is there

any way
> > with
> > > the asp.net framework to exchange data between different

application?

> > >
> > > I basically need to send message to a 'server wide' application from any
>
> > > HttpApplication on the same server and obtain responses (wich may be

> > simple
> > > strings or streams for example), this 'server wide' application

is also
> > > HttpApplication.
> > >
> > > If such feature doesn't exist, is this a place for remoting?
> > >
> > > If this is a place for remoting did you have some hints on how I
should
> > host
> > > the remoting server in my 'server wide' HttpApplication (keeping
simple
> > > deployment in mind)?
> > >
> > > Thanks for any thoughts.
> > >
> > > Gauthier
> > >
> > >
> >
> >
>
>

[Alvin Bruney]

This isn't built in. You may write a service to do that but it's difficult
to do since the OS scheduler isn't guaranteed to start services in a
particular order. Better said, the service which start aren't guaranteed to
start in a particular order, so you aren't guaranteed that because iis
service starts before your service that iis will actually end up running
before your service resulting in errors on your part from this discrapency.

I suggest you go with option 2.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"[Gauthier]" <ms****@ifrance.com> wrote in message
news:e$**************@tk2msftngp13.phx.gbl...

Hello,

I've missexplained my problem here:

My problem is that my 'server wide' HttpApplication is not allready started in some case (for exemple just after saving the web.config of the
application).

Since I initialize my Channel in the Application_Start event, it's ok if the application is allready started (for exemple just after a web request on
this application was made).

But i'm getting SocketException with the following message: 'No connection
could be made because the target machine actively refused it' when the
application is not allready started.

So the solution would be:
1: find a way to start the application when iis service is starting and
expecting that the application is not recycled is no request are made on it after a period of time (is there such behavior in the asp.net framework?)

2: find a way to check that the channel exist (the 'server wide' application is allready started) in my client remotefacade.

I've allready think about a possible implementation of the second solution
but the primmer seems simpler if it's possible and I don't know wether it is or not.

Anyway I have to make such test (the second solution) to ensure that the
'server wide' application has registered the channel, for the sake of
robustness.

Thanks

Gauthier

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:#K**************@TK2MSFTNGP12.phx.gbl...

you don't need to explicitly check for it. just make the call. the
application object and everthing related to it will either honor the request

if it is running or the runtime will first create and run the application,

initializing all the relevant objects before honoring the call.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"[Gauthier]" <ms****@ifrance.com> wrote in message
news:eZ*************@tk2msftngp13.phx.gbl...

Thanks, I've succesfully implemented a quick test and registered a
tcpchannel in my Global.asax.cs and it's work succesfully: I can call

simple

methods from a remote application.

Now I've a simple question:
Is there an clean way to ensure that an httpapplication is allready

started

(for my 'server wide' application), because my client applications need

that

the httpapplication is started to make remote method calls, and it's fail

if

the 'server wide' application is not started?

A simple solution I've think about is to make some 'activation

httprequests'

on the 'server wide' application in my client applications, but that

seams

a

dirty solution if there is a more convinient way to autostart
httpapplications with iis or such thing.

Thanks for insight.

Gauthier

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote

in message news:Os*************@tk2msftngp13.phx.gbl...
> Remoting is the replacement for all things DCOM. It will allow you, for > example, to push data thru one process boundary into another running
process
> which is what I think you are after. I'd suggest you start reading

up before
> you dive in because a couple issues can bite you. Look at ingo

rammar's > book, it's the definitive work on remoting.
>
> --
>
>
> -----------
> Got TidBits?
> Get it here: www.networkip.net/tidbits
> "[Gauthier]" <ms****@ifrance.com> wrote in message
> news:Oy**************@TK2MSFTNGP09.phx.gbl...
> > Thanks for your reply,
> >
> > I'm more interested with remoting in place of xml web service because it's
> a
> > communication between 2 process that live on the same machine and also for
> > performances reason.
> >
> > Could you tell me how IIS can host such remote process?
> >
> > A solution I was thinking about was having a

System.Diagnostics.Process

> > launched in Global.asax.cs within the Application_Start event, a

console

> > process with standard I/O, so I could manage to get the ProcessId in other
> > HttpApplication and get a reference on that process, but I'm wondering if
> > remoting and all stuffs that come along wouldn't be a better solution. > >
> > I'm almost concerned with request concurrency (many apps that make
request
> > on the 'server wide' application) and I imagine this could be an issue if
> I
> > use standard I/O of the process as the sole way to communicate.
> >
> > So does the solution would be a dedicated process hosted in IIS that > > communicate with my httpapps with a remoting client over tcp messages > would
> > be the good one?
> >
> > Will I have to investigate on threads issues or bottleneck to

implement

a
> > such process? (that's surely why xml web service and http

communication

> > 'simplify' a lot of stuffs)
> >
> > Thanks for assistance & best regards
> >
> > Gauthier
> >
> > "Sherif ElMetainy" <el*************@wayout.net.NOSPAM> wrote in

message

> > news:eE*************@tk2msftngp13.phx.gbl...
> > > Hello
> > >
> > > I suggeest using xml web services. Remoting can be used too, and it can
> be
> > > hosted in IIS, without the need for a separate process. Both

solutions

> are
> > > simple in deploymen, but the xml web service approach is simpler in > > > implementation.
> > >
> > > Best regards,
> > > Sherif
> > >
> > > "[Gauthier]" <ms****@ifrance.com> wrote in message
> > > news:OE**************@TK2MSFTNGP11.phx.gbl...
> > > > Hello,
> > > >
> > > > I've a simple question:
> > > >
> > > > On a server that run multiple asp.net HttpApplication, is there any

> way
> > > with
> > > > the asp.net framework to exchange data between different
application?
> > > >
> > > > I basically need to send message to a 'server wide'

application

from

> any
> >
> > > > HttpApplication on the same server and obtain responses (wich

may

be

> > > simple
> > > > strings or streams for example), this 'server wide'

application is > also
> > > > HttpApplication.
> > > >
> > > > If such feature doesn't exist, is this a place for remoting?
> > > >
> > > > If this is a place for remoting did you have some hints on how

I > should
> > > host
> > > > the remoting server in my 'server wide' HttpApplication (keeping > simple
> > > > deployment in mind)?
> > > >
> > > > Thanks for any thoughts.
> > > >
> > > > Gauthier
> > > >
> > > >
> > >
> > >
> >
> >
>
>