[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

.rem file as objectUri in wellknown element? how is it created?

Greg

10/1/2004 2:32:00 PM

objectUri - Specifies the endpoint of the object's Uniform Resource
Identifier (URI).

When an object is hosted in Internet Information Services (IIS), the
objectUri extension must be .soap or .rem, so that the request is routed to
the .NET Remoting IHttpHandler.

O.K. but how is the .rem file created that is hosted in IIS?

thx, -hazz





4 Answers

Ken Kolda

10/1/2004 3:02:00 PM

0

There is not actual, physical .rem file. The .rem extension tells .NET that
the request is for a remoting object, so instead of looking for a file to
process (as in the case of ".aspx"), it looks for a remoted object in the
application.

Ken


"hazz" <hazz@sonic.net> wrote in message
news:uAdjfN8pEHA.3876@TK2MSFTNGP15.phx.gbl...
> objectUri - Specifies the endpoint of the object's Uniform Resource
> Identifier (URI).
>
> When an object is hosted in Internet Information Services (IIS), the
> objectUri extension must be .soap or .rem, so that the request is routed
to
> the .NET Remoting IHttpHandler.
>
> O.K. but how is the .rem file created that is hosted in IIS?
>
> thx, -hazz
>
>
>
>
>


Greg

10/1/2004 3:27:00 PM

0

Thank you Ken!
So
<wellknown mode="Singleton" type= "XXX.remotingobject" objectUri =
"RemotingObject.rem"/>
tells the client or service to track down it's corresponding endpoint (with
the type="") by looking for the assembly info (assuming it's in the GAC?)
and the objectUri. I guess I am still confused by how the objectUri is
located. It is not like a url which is referenced against an IIS virtual
directory/path/filename.
So if this config file instruction is telling .NET not to look for a file
but rather a remoted object in the application, where is that? Is it telling
..NET to use the type info which precedes the objectUri info?
Or is there some statement in the application code that is supposed to be
utilized?
I guess I wasn't real clear on what is meant by looking for the remoted
object in the application?
Thanks again,
-greg

"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
news:eWdV5e8pEHA.3848@TK2MSFTNGP14.phx.gbl...
> There is not actual, physical .rem file. The .rem extension tells .NET
that
> the request is for a remoting object, so instead of looking for a file to
> process (as in the case of ".aspx"), it looks for a remoted object in the
> application.
>
> Ken
>
>
> "hazz" <hazz@sonic.net> wrote in message
> news:uAdjfN8pEHA.3876@TK2MSFTNGP15.phx.gbl...
> > objectUri - Specifies the endpoint of the object's Uniform Resource
> > Identifier (URI).
> >
> > When an object is hosted in Internet Information Services (IIS), the
> > objectUri extension must be .soap or .rem, so that the request is routed
> to
> > the .NET Remoting IHttpHandler.
> >
> > O.K. but how is the .rem file created that is hosted in IIS?
> >
> > thx, -hazz
> >
> >
> >
> >
> >
>
>


Ken Kolda

10/1/2004 4:03:00 PM

0

OK, here's a rough approximation of what occurs when you host a remoting
object under IIS. First, assume you've created an object that derives from
MarshalByRefObject called RemoteObject. You then created a new web
application virtual root under IIS called MyWebApp and you put your assembly
containing the RemoteObject in the bin folder beneath this virtual root.
Finally, you created a web.config file that includes the item:

<wellknown mode="Singleton" type="MyNamespace.RemoteObject, MyAssembly"
objectUri="RemoteObject.rem"/>

You now create a remoting client that, within it's code, includes the
following line:

RemoteObject o = (RemoteObject) Activator.GetObject(typeof(RemoteObject),
"http://myserver/MyWebApp/RemoteObject.rem");

Here's what happens:

1) The client connects to the web server via HTTP and requests th page
"/MyWebApp/RemoteObject.rem".
2) IIS looks at the path information in the URI, /MyWebApp, and sees this is
a registered web application.
3) IIS looks to see if the web application has an "App Mapping" registered
for the ".rem" file extension. Assuming .NET is installed and IIS is
properly configured, it will find that this extension is mapped to the .NET
ISAPI extension, aspnet_isapi.dll.
4) The properties of this App Mapping tell IIS to forward the call to the
ISAPI DLL without first checking if a file with the given name
(RemoteObject.rem) exists. (To see this, go to the App Mappings tab of the
web app's properties in the IIS Management Console, locate ".rem" and click
Edit. You'll see the checkbox "Check that file exists" turned off.).
5) IIS passes the request to the .NET ISAPI extension, which first checks if
the web app is running. If not, the app is started. This causes the
web.config to be read and the wellknown object to be registered with the
remoting infrastructure.
6) The ISAPI extension parses the file name (RemoteObject.rem) and, based on
its extension, loads the HttpHandler for remoting requests. To do this, it
looks for the <httpHandlers> section of the machine.config (or the app's
web.config if an <httpHandlers> section is present).
7) The default machine.config file maps "*.rem" to the
HttpRemotingHandlerFactory, which provides the IHttpHandler for processing
remoting calls. The ISAPI create a new handler and passes the handler the
request. (Note: Up to this point, the processing would have been exactly the
same if the extension were .aspx, but an aspx extension would cause the
ISAPI to load the PageHandlerFactory).
8) The remoting request handler looks through the registered well-known
types to find the one that matches the URI passes to it. In this case, the
URI "RemoteObject.rem" maps to the RemoteObject type.
9) Since the RemoteObject declared as a singleton, an instance is created if
it doesn't already exist. The binary- or soap-formatted message contained in
the body of the request is then deserialized by handler and the method call
is invoked.
10) The return value and out/ref parameters are then serialized and returned
in the body of the HTTP request.

The main thing to understand is that the URI you pass to IIS
(RemoteObject.rem) doesn't always have to correspond to a physical process.
If the extension maps to an ISAPI extension, it's completely up to that
extension to decide how to handle the request.

Ken



"hazz" <hazz@sonic.net> wrote in message
news:usESYs8pEHA.800@TK2MSFTNGP14.phx.gbl...
> Thank you Ken!
> So
> <wellknown mode="Singleton" type= "XXX.remotingobject" objectUri =
> "RemotingObject.rem"/>
> tells the client or service to track down it's corresponding endpoint
(with
> the type="") by looking for the assembly info (assuming it's in the GAC?)
> and the objectUri. I guess I am still confused by how the objectUri is
> located. It is not like a url which is referenced against an IIS virtual
> directory/path/filename.
> So if this config file instruction is telling .NET not to look for a file
> but rather a remoted object in the application, where is that? Is it
telling
> .NET to use the type info which precedes the objectUri info?
> Or is there some statement in the application code that is supposed to be
> utilized?
> I guess I wasn't real clear on what is meant by looking for the remoted
> object in the application?
> Thanks again,
> -greg
>
> "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
> news:eWdV5e8pEHA.3848@TK2MSFTNGP14.phx.gbl...
> > There is not actual, physical .rem file. The .rem extension tells .NET
> that
> > the request is for a remoting object, so instead of looking for a file
to
> > process (as in the case of ".aspx"), it looks for a remoted object in
the
> > application.
> >
> > Ken
> >
> >
> > "hazz" <hazz@sonic.net> wrote in message
> > news:uAdjfN8pEHA.3876@TK2MSFTNGP15.phx.gbl...
> > > objectUri - Specifies the endpoint of the object's Uniform Resource
> > > Identifier (URI).
> > >
> > > When an object is hosted in Internet Information Services (IIS), the
> > > objectUri extension must be .soap or .rem, so that the request is
routed
> > to
> > > the .NET Remoting IHttpHandler.
> > >
> > > O.K. but how is the .rem file created that is hosted in IIS?
> > >
> > > thx, -hazz
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>


Greg

10/1/2004 6:52:00 PM

0

whoa...thank you for this Ken!
that really really helps.
Based on your explanation, I just found the files utilizing
Activator.GetObject to show me where the client code exists.
you gave me an excellent visceral feel for what is going on. There are
indeed a few moving parts. ;-)
Appreciatively,
-greg

"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
news:%23OqDGB9pEHA.3712@TK2MSFTNGP15.phx.gbl...
> OK, here's a rough approximation of what occurs when you host a remoting
> object under IIS. First, assume you've created an object that derives from
> MarshalByRefObject called RemoteObject. You then created a new web
> application virtual root under IIS called MyWebApp and you put your
assembly
> containing the RemoteObject in the bin folder beneath this virtual root.
> Finally, you created a web.config file that includes the item:
>
> <wellknown mode="Singleton" type="MyNamespace.RemoteObject, MyAssembly"
> objectUri="RemoteObject.rem"/>
>
> You now create a remoting client that, within it's code, includes the
> following line:
>
> RemoteObject o = (RemoteObject) Activator.GetObject(typeof(RemoteObject),
> "http://myserver/MyWebApp/RemoteObject.rem");
>
> Here's what happens:
>
> 1) The client connects to the web server via HTTP and requests th page
> "/MyWebApp/RemoteObject.rem".
> 2) IIS looks at the path information in the URI, /MyWebApp, and sees this
is
> a registered web application.
> 3) IIS looks to see if the web application has an "App Mapping" registered
> for the ".rem" file extension. Assuming .NET is installed and IIS is
> properly configured, it will find that this extension is mapped to the
..NET
> ISAPI extension, aspnet_isapi.dll.
> 4) The properties of this App Mapping tell IIS to forward the call to the
> ISAPI DLL without first checking if a file with the given name
> (RemoteObject.rem) exists. (To see this, go to the App Mappings tab of the
> web app's properties in the IIS Management Console, locate ".rem" and
click
> Edit. You'll see the checkbox "Check that file exists" turned off.).
> 5) IIS passes the request to the .NET ISAPI extension, which first checks
if
> the web app is running. If not, the app is started. This causes the
> web.config to be read and the wellknown object to be registered with the
> remoting infrastructure.
> 6) The ISAPI extension parses the file name (RemoteObject.rem) and, based
on
> its extension, loads the HttpHandler for remoting requests. To do this, it
> looks for the <httpHandlers> section of the machine.config (or the app's
> web.config if an <httpHandlers> section is present).
> 7) The default machine.config file maps "*.rem" to the
> HttpRemotingHandlerFactory, which provides the IHttpHandler for processing
> remoting calls. The ISAPI create a new handler and passes the handler the
> request. (Note: Up to this point, the processing would have been exactly
the
> same if the extension were .aspx, but an aspx extension would cause the
> ISAPI to load the PageHandlerFactory).
> 8) The remoting request handler looks through the registered well-known
> types to find the one that matches the URI passes to it. In this case, the
> URI "RemoteObject.rem" maps to the RemoteObject type.
> 9) Since the RemoteObject declared as a singleton, an instance is created
if
> it doesn't already exist. The binary- or soap-formatted message contained
in
> the body of the request is then deserialized by handler and the method
call
> is invoked.
> 10) The return value and out/ref parameters are then serialized and
returned
> in the body of the HTTP request.
>
> The main thing to understand is that the URI you pass to IIS
> (RemoteObject.rem) doesn't always have to correspond to a physical
process.
> If the extension maps to an ISAPI extension, it's completely up to that
> extension to decide how to handle the request.
>
> Ken
>
>
>
> "hazz" <hazz@sonic.net> wrote in message
> news:usESYs8pEHA.800@TK2MSFTNGP14.phx.gbl...
> > Thank you Ken!
> > So
> > <wellknown mode="Singleton" type= "XXX.remotingobject" objectUri =
> > "RemotingObject.rem"/>
> > tells the client or service to track down it's corresponding endpoint
> (with
> > the type="") by looking for the assembly info (assuming it's in the
GAC?)
> > and the objectUri. I guess I am still confused by how the objectUri is
> > located. It is not like a url which is referenced against an IIS virtual
> > directory/path/filename.
> > So if this config file instruction is telling .NET not to look for a
file
> > but rather a remoted object in the application, where is that? Is it
> telling
> > .NET to use the type info which precedes the objectUri info?
> > Or is there some statement in the application code that is supposed to
be
> > utilized?
> > I guess I wasn't real clear on what is meant by looking for the remoted
> > object in the application?
> > Thanks again,
> > -greg
> >
> > "Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
> > news:eWdV5e8pEHA.3848@TK2MSFTNGP14.phx.gbl...
> > > There is not actual, physical .rem file. The .rem extension tells .NET
> > that
> > > the request is for a remoting object, so instead of looking for a file
> to
> > > process (as in the case of ".aspx"), it looks for a remoted object in
> the
> > > application.
> > >
> > > Ken
> > >
> > >
> > > "hazz" <hazz@sonic.net> wrote in message
> > > news:uAdjfN8pEHA.3876@TK2MSFTNGP15.phx.gbl...
> > > > objectUri - Specifies the endpoint of the object's Uniform Resource
> > > > Identifier (URI).
> > > >
> > > > When an object is hosted in Internet Information Services (IIS), the
> > > > objectUri extension must be .soap or .rem, so that the request is
> routed
> > > to
> > > > the .NET Remoting IHttpHandler.
> > > >
> > > > O.K. but how is the .rem file created that is hosted in IIS?
> > > >
> > > > thx, -hazz
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>