High Level View of a .Net Application

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

Guest

This is a wildly broad question, so apologies in advance.

I developed a very traditional app architecture in Visual Studio 5-6.
The basic structure looked like this:
GUI >> MTS >> Database
The basic idea here was Users talk to the object, the object logs in to the
database as itself and does some work.

Perhaps I'm being overly dense, but I cannot seem to find a good writeup on
the preferred way to implement this in .Net. Can someone point me to a good
overview of how to implement something like this in .Net?


Here's a specific example I want to implement if you're interested...
A 3rd party app we use requires SQL Authentication. I'm sick of resettng
passwords.
I wrote a "clsPassword" object that has a "Reset" method, and I want to let
help desk people use it to reset passwords.
In SQL Server, you have to be an admin to reset a password.
clsPassword protects itself with certain business rules.
I want to implement clsPassword in the middle tier as an admin so that
non-admins can use its limited functionality.
In Visual Studio 6, this would be ultra-simple. I'd just toss my object
into COM+, configure it with an admin account, and go along my merry way.

At this point, I don't see a clear way to do this in .Net. Is this
something I'd need to implement a web service for?

Thanks, and sorry for the nooobish question.
 
you can still host your component in COM+
http://www.15seconds.com/issue/030501.htm

As an alternative, you can create a .Net app that runs in the context of
another user by using "impersonate=true" in the app config or web config and
simply providing the credentials in that spot (or encrypted in the
registry).

See http://support.microsoft.com/default.aspx?scid=kb;en-us;329290

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
 
Thank you for the input.
Both of those appear to be viable options. Maybe I'm being too picky, but
they just don't feel "right".

In VS6, you configured a middle tier and could easily manage who had access
to the middle tier via an admin console (COM+).

COM InterOp is mainly for backward compatibility, right? As I move my
company forward, I feel like I should be using pure .Net and not relying on
old technologies.

The other option involves putting code directly into the object to indicate
its security and who can use it. While that will work, it feels like a
significant step backward from administering that security in a nice MMC
plug-in.

From your experience, how do the bulk of companies make this transition?

From what I've seen, a web service would kinda fill this gap. It appears
you'd just do your administration in IIS.

Thanks again for the initial reply. It gives me something with which to
work. I'd be interested to hear your thoughts on the questions I pose above.
 
Hi Shawn,

I embedded my comments into the text...

Shawn Brock said:
Thank you for the input.
Both of those appear to be viable options. Maybe I'm being too picky, but
they just don't feel "right".

In VS6, you configured a middle tier and could easily manage who had access
to the middle tier via an admin console (COM+).

COM InterOp is mainly for backward compatibility, right? As I move my
company forward, I feel like I should be using pure .Net and not relying on
old technologies.
Click to expand...

COM+ and COM Interop are two different things. That's why we've renamed
COM+ to Component Services. Microsoft has no intention of losing the
functionality of the Application Server. Certainly future versions of the
platform will have Component Services, with a console for managing
components, identities, etc. Think of it as a case of unfortunate naming.
(like naming a child John Wilkes Booth. You get what I mean?)

So you are not relying on an old technology to use Component Services to
manage your components written in .Net.
The other option involves putting code directly into the object to indicate
its security and who can use it. While that will work, it feels like a
significant step backward from administering that security in a nice MMC
plug-in.
Click to expand...

The ability to declare the identity that a component can run under, without
resorting to the overhead of a transaction manager like Component Services,
is a huge win. We get a great deal of flexibility that our Unix friends
have had for a long time, and it is an important capability for managing the
access of data to resources. Just like a stored procedure can be run by
'Joe' and the stored procedure can insert a record, even though 'Joe' cannot
insert a record, it is important that we provide the ability, to individual
developers, to make little 'gateways' to system resources. The fact that
the identity is not in the code, but rather in its configuration, means that
the code itself is not directly managing its own security. This is also
important for the Windows platform to achieve the level of security that
customers demand.

Far from a step backwards, it is a necessary ability in a competitive world.
From your experience, how do the bulk of companies make this transition?
Click to expand...

With a little learning. It takes time to take all of it in. Usually one or
two folks in any group will be the early adopters... the ones who embrace
without challenge. Everyone else needs convincing to some degree. You are
far from alone.
From what I've seen, a web service would kinda fill this gap. It appears
you'd just do your administration in IIS.
Click to expand...

Actually, you can do you admin in IIS (using app pools) or in the config
files. Either way, web services do work for this. On the other hand,
adding a web service, for some applications, is the wrong architectural
choice. You have to add them at the right depth, and you have to make sure
that security is provided so access to your data is fully controlled. You
may also introduce performance implications unless you are careful. In
other words, Web services are a tool, not a silver bullet.
Thanks again for the initial reply. It gives me something with which to
work. I'd be interested to hear your thoughts on the questions I pose
Click to expand...
above.

I hope this helps,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
I really appreciate the thorough and thoughtful reply.
I've read it once, but feel I'm going to need to re-read all you've written
on this thread and dig in a little deeper.

I'm probably behaving a little too myopic. I know what I had, and I liked
it (well except regsvr32...). I'm trying to fit .Net perfectly into the
older DNA, and that's probably the wrong approach. The general design is
similar, but I need to be more open to my changing my middle tier
implementation.

Thanks again for the excellent input.
I'm going to move forward with the encrpyted configuration and see how my
first pass goes.
 
Back
Top