Remoting

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi
I posted a similar question like this to a reply to another thread but it
wasn't really relevant to that thread and I don't think anybody read it so
I'm posting a new one.

I'm trying to think of a use for remoting in the workplace, but can't. I
want to look cool by "running commands over the network" and using "virtual
server application protocols" that would make me look the don in front of
bosses and probably gain me a pay rise, even though the company wouldn't
actually be able to do anything better or more than it could before.

What sort of applications have people used the old DCOM for in the past?

Any ideas?

Thanks
 
You could make a remote workstation monitoring tool, that would basically
let anyone using the program can view what is happening on the remote
machine, like check running processes, access registry etc. Could be a great
network management tool.
 
I can't think of what's on the workstation that they'd want to know that
isn't on the network.
 
..Net remoting gives you the same features as Javabeans, since you can host a
remoted object in IIS, so start there... .NET needs it because the other
guys have it. (safer than running in Com+, plus easier to install and
configure).

As for why use it:
If you have many applications running on different machines, you may run
into a situation where you need to have two server applications talk to each
other.
In real time.

Now, you could place data into database tables, and have the apps take turns
reading and writing, but that's slow and a poor use of database resources.

You could hard-wire the apps together, but you radically increase risk of
causing one or both to fail if the other one is having problems, or code
changes, or hardware changes, etc.

..Net remoting provides a nice interface to support configuration changes
when connecting two server-based applications. That's one good reason for
it.

Another: it supports async communication. So a client can sign up to get a
message from a server... and the server can send it later. If the client is
not around, this is easy to catch (or ignore) and neither system has to jump
through hoops to worry about this situtaion.

Another good reason is the ability to host a particularly sensitive assembly
on a server where you wouldn't want to host it on the clients. Perhaps the
code is highly sensitive in nature (assemblies can be uncompiled)... perhaps
it needs to access additional resources that can't be reached from the
client directly... perhaps it needs to change daily... perhaps it needs to
be aware of the things that other client apps are doing... then .NET
remoting works very well.

In my work, we have an application that contains very sensitive data. The
security people want us to encrypt all of the sensitive fields. However,
this makes it difficult to search the data, especially when the users simply
must have the ability to query using wildcards. That would make the app run
very very very slowly. One way around this: place the database on a
seperate network. On a machine that is shared between the two networks,
place some remoting components. Put in high authorization and security
provisions in the code in the "gateway" object. Now, there's no way to get
to the data except through this object. This raises security without
destroying performance.


This is just an off-the-top-of-my-head list. I hope it helps,
--- Nick Malik
 
Back
Top