Best Means: Calling a Function or Application on a Remote Server

[jehugaleahsa]

Hello:

Our users have an application where they can initiate jobs on our
servers. Currently, we have Oracle stored procedures that execute
applications on the database server. We hate using the database this
way.

We would like our applications to be run without needing to initiate
them with a database.

We are currently gathering information on the approaches we can take.
What are some options?

What would be the most scalable option?

How do we authenticate users? What other security measures do we need
to take?

What needs to be on the machine in order for the code to run?

Most of our applications need the database SID, user name and password
passed in. How can pass this information securely? (We can always use
Oracle proxy authentication.)

Thanks for any pointers!

~Travis

 

[Ignacio Machin ( .NET/ C# MVP )]

Hello:

Our users have an application where they can initiate jobs on our
servers. Currently, we have Oracle stored procedures that execute
applications on the database server. We hate using the database this
way.

We would like our applications to be run without needing to initiate
them with a database.

We are currently gathering information on the approaches we can take.
What are some options?

What would be the most scalable option?

How do we authenticate users? What other security measures do we need
to take?

What needs to be on the machine in order for the code to run?

Most of our applications need the database SID, user name and password
passed in. How can pass this information securely? (We can always use
Oracle proxy authentication.)

Thanks for any pointers!

~Travis

Hi,

First of all, what kind of applications?

A web service could be a solution.

 

[Cor Ligthert[MVP]]

Hi,

I think that the change to get a good answer is mainly in the newsgroup
microsoft.public.dotnet.framework.adonet

As there are too Oracle user active.
(Here too but there more)

Cor

 

[Pavel Minaev]

Hello:

Our users have an application where they can initiate jobs on our
servers. Currently, we have Oracle stored procedures that execute
applications on the database server. We hate using the database this
way.

We would like our applications to be run without needing to initiate
them with a database.

We are currently gathering information on the approaches we can take.
What are some options?

If I understand you correctly, you essentially want to do RPC between
two machines. In that case...

The default one would be a Web service (easiest to write, popular
approach so lots of examples/tutorials, good integrated
security). .NET remoting is another option. Then of course there's COM
+ components and MSMQ.

What would be the most scalable option?

Depends on your scenario, and on how you implement the server side.
All of them are potentially scalable.

How do we authenticate users?

If you're using .NET in a Windows-only environment with a domain, then
integrated Windows authentication seems to be the most logical
solution. Both ASP.NET web services and WCF support it out of the box,
you just need to configure them to do it.

What other security measures do we need to take?

Hard to say without knowing what you do, but you might want to protect
the data that is transmitted from clients to the server. If you use
Web services for that, then you'd just use SSL/TLS.

What needs to be on the machine in order for the code to run?

For any .NET solution - .NET, obviously. Anything else is optional;
with WCF, you can have a self-hosting Web service application, for
example, and .NET remoting has always allowed to embed hosts into .exe

In practice, most people host their Web services in IIS.

Most of our applications need the database SID, user name and password
passed in. How can pass this information securely? (We can always use
Oracle proxy authentication.)

If you use Windows integrated authentication and WCF, you needn't
worry - it will handle it all in a secure way.

 

[jehugaleahsa]

If I understand you correctly, you essentially want to do RPC between
two machines. In that case...

The default one would be a Web service (easiest to write, popular
approach so lots of examples/tutorials, good integrated
security). .NET remoting is another option. Then of course there's COM
+ components and MSMQ.


Depends on your scenario, and on how you implement the server side.
All of them are potentially scalable.


If you're using .NET in a Windows-only environment with a domain, then
integrated Windows authentication seems to be the most logical
solution. Both ASP.NET web services and WCF support it out of the box,
you just need to configure them to do it.


Hard to say without knowing what you do, but you might want to protect
the data that is transmitted from clients to the server. If you use
Web services for that, then you'd just use SSL/TLS.


For any .NET solution - .NET, obviously. Anything else is optional;
with WCF, you can have a self-hosting Web service application, for
example, and .NET remoting has always allowed to embed hosts into .exe

In practice, most people host their Web services in IIS.


If you use Windows integrated authentication and WCF, you needn't
worry - it will handle it all in a secure way.

Well, you named some technologies. That is what I am looking for. I
suggested Web services myself; we would probably just go the IIS
route. I am not sure if our sys admins would appreciate that.

I will look into .NET remoting, too. I want to weight all our options
before I push for anything.

Thanks!

 

[jehugaleahsa]

If I understand you correctly, you essentially want to do RPC between
two machines. In that case...

The default one would be a Web service (easiest to write, popular
approach so lots of examples/tutorials, good integrated
security). .NET remoting is another option. Then of course there's COM
+ components and MSMQ.


Depends on your scenario, and on how you implement the server side.
All of them are potentially scalable.


If you're using .NET in a Windows-only environment with a domain, then
integrated Windows authentication seems to be the most logical
solution. Both ASP.NET web services and WCF support it out of the box,
you just need to configure them to do it.


Hard to say without knowing what you do, but you might want to protect
the data that is transmitted from clients to the server. If you use
Web services for that, then you'd just use SSL/TLS.


For any .NET solution - .NET, obviously. Anything else is optional;
with WCF, you can have a self-hosting Web service application, for
example, and .NET remoting has always allowed to embed hosts into .exe

In practice, most people host their Web services in IIS.


If you use Windows integrated authentication and WCF, you needn't
worry - it will handle it all in a secure way.

If using a web service, can I allow the method to wait indefinitely?
Some of our processes take hours to run. It might not matter in the
long run, but it is good to know. For instance, we might some day want
to asynchronously call a service method and have it indicate
completion.

It would be even more cool if we could raise some sort of events,
where we could regularly update the status of the process. We can
technically do that on the database side, but it would be even cooler
if the service could handle it.