«

Greetings,

My company has an ASP.NET based enterprise product that is undergoing some
changes and I need some community input to help solve a problem.

In the current implementation, any given installation of the product
supports only one database at a time. The server/db information is stored in
the registry on the computer hosting the com+ based middle tier. We are now
moving to a solution which supports multiple databases. That is, the user is
able to select from a list of available dbs at login.

Because of this change, the registry information the middle tier uses to
build up the db connection string is obviously no longer available. The key
information required now lives on the machine hosting the presentation layer
(web server). Since I want to avoid passing the server/db information with
every call into the middle tier, I have implemented a solution using
IISIntrinsics to retrieve Session information (where I store the server/db
properties). It works very well, but there is a great deal of consternation
from the powers that be about the implementation and the possible impact on
performance.

For IISIntrinsics to work, all the .aspx pages must have ASPCompat="true"
added to the Page directive. This now means that we move from our pages
running in MTA to running in STA. We have no native COM components running
on any of our pages, so it is frustrating to have to set this flag when all I
want are the Intrinsics of the page.

I am wondering how other people have implemented solutions where the
presentation layer has to provide the middle tier with connection
information. I understand that Whidbey will not support ASPCompat, so does
anyone know if there will be a way to retrieve Session data from a com+
component hosted on another machine?

Cheers, Ian Williamson

I'm not sure I even understand half of what you wrote. It started out
clearly enough. It seems you were storing connection information in the
System Registry. Apparenlty, you needed to scale this to support multiple
databases, which I imagine means multiple sets of connection information.
However, after that it gets kind of fuzzy.

First, you never indicated what made you decide to change your design. You
can store as many Connection Strings, etc. in the Registry that you want.
Personally, I wouldn't even USE the registry (that's what web.config is
for), but I can't figure out why you had to redesign the entire app instead
of just that little section.

> The key
> information required now lives on the machine hosting the presentation
> layer
> (web server).

This is fuzzy. It indicates that "information" (data) resides on a machine.
That's all. It doesn't specify what form the data is in, how it is stored,
etc.

> Since I want to avoid passing the server/db information with
> every call into the middle tier, I have implemented a solution using
> IISIntrinsics to retrieve Session information (where I store the server/db
> properties). It works very well, but there is a great deal of
> consternation
> from the powers that be about the implementation and the possible impact
> on
> performance.

Okay, you start out here with a requirement, which is easy enough to
decipher. However, your solution definitely sounds weird. First of all, it
apparently refers to Session information on the web server, so I assume that
Session is being used in some context on the web server, and that this is
somehow related to the "Key information" that is stored on the web server.
However, what that relationship is, is not mentioned.

Assuming that the "middle tier" is a set of DLLs that reside in your web
application, on the web server, in the app's bin folder, there is no need
for such a gerrymandered solution. A business class can access the entire
HttpContext of a Request via HttpContext.Current. This includes Application,
Session, Server, Handler, and a few others.

Now, if you had implemented this solution, all of the COM+ issues would
disappear. Interop is generally a thing to be avoided with .Net. Still, I
can't help but think I must be missing something.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

"Ian Williamson" <Ian > wrote in message
news8E39980-63A3-4DBC-B198-...
> Greetings,
>
> My company has an ASP.NET based enterprise product that is undergoing some
> changes and I need some community input to help solve a problem.
>
> In the current implementation, any given installation of the product
> supports only one database at a time. The server/db information is stored
> in
> the registry on the computer hosting the com+ based middle tier. We are
> now
> moving to a solution which supports multiple databases. That is, the user
> is
> able to select from a list of available dbs at login.
>
> Because of this change, the registry information the middle tier uses to
> build up the db connection string is obviously no longer available. The
> key
> information required now lives on the machine hosting the presentation
> layer
> (web server). Since I want to avoid passing the server/db information
> with
> every call into the middle tier, I have implemented a solution using
> IISIntrinsics to retrieve Session information (where I store the server/db
> properties). It works very well, but there is a great deal of
> consternation
> from the powers that be about the implementation and the possible impact
> on
> performance.
>
> For IISIntrinsics to work, all the .aspx pages must have ASPCompat="true"
> added to the Page directive. This now means that we move from our pages
> running in MTA to running in STA. We have no native COM components
> running
> on any of our pages, so it is frustrating to have to set this flag when
> all I
> want are the Intrinsics of the page.
>
> I am wondering how other people have implemented solutions where the
> presentation layer has to provide the middle tier with connection
> information. I understand that Whidbey will not support ASPCompat, so
> does
> anyone know if there will be a way to retrieve Session data from a com+
> component hosted on another machine?
>
> Cheers, Ian Williamson
>
>

Hi Ian

Is it just the problem of storing connection string for a user session or
there is something else also that you want to store for a user session?

Vaibhav

"Ian Williamson" <Ian > wrote in message
news8E39980-63A3-4DBC-B198-...
> Greetings,
>
> My company has an ASP.NET based enterprise product that is undergoing some
> changes and I need some community input to help solve a problem.
>
> In the current implementation, any given installation of the product
> supports only one database at a time. The server/db information is stored
> in
> the registry on the computer hosting the com+ based middle tier. We are
> now
> moving to a solution which supports multiple databases. That is, the user
> is
> able to select from a list of available dbs at login.
>
> Because of this change, the registry information the middle tier uses to
> build up the db connection string is obviously no longer available. The
> key
> information required now lives on the machine hosting the presentation
> layer
> (web server). Since I want to avoid passing the server/db information
> with
> every call into the middle tier, I have implemented a solution using
> IISIntrinsics to retrieve Session information (where I store the server/db
> properties). It works very well, but there is a great deal of
> consternation
> from the powers that be about the implementation and the possible impact
> on
> performance.
>
> For IISIntrinsics to work, all the .aspx pages must have ASPCompat="true"
> added to the Page directive. This now means that we move from our pages
> running in MTA to running in STA. We have no native COM components
> running
> on any of our pages, so it is frustrating to have to set this flag when
> all I
> want are the Intrinsics of the page.
>
> I am wondering how other people have implemented solutions where the
> presentation layer has to provide the middle tier with connection
> information. I understand that Whidbey will not support ASPCompat, so
> does
> anyone know if there will be a way to retrieve Session data from a com+
> component hosted on another machine?
>
> Cheers, Ian Williamson
>
>

Do not use the UI to pass the information to the middle tier, have the middle
tier (or the UI if you must), get the connection from a factory in the middle
tier. See the factory pattern.

"Ian Williamson" wrote:

> Greetings,
>
> My company has an ASP.NET based enterprise product that is undergoing some
> changes and I need some community input to help solve a problem.
>
> In the current implementation, any given installation of the product
> supports only one database at a time. The server/db information is stored in
> the registry on the computer hosting the com+ based middle tier. We are now
> moving to a solution which supports multiple databases. That is, the user is
> able to select from a list of available dbs at login.
>
> Because of this change, the registry information the middle tier uses to
> build up the db connection string is obviously no longer available. The key
> information required now lives on the machine hosting the presentation layer
> (web server). Since I want to avoid passing the server/db information with
> every call into the middle tier, I have implemented a solution using
> IISIntrinsics to retrieve Session information (where I store the server/db
> properties). It works very well, but there is a great deal of consternation
> from the powers that be about the implementation and the possible impact on
> performance.
>
> For IISIntrinsics to work, all the .aspx pages must have ASPCompat="true"
> added to the Page directive. This now means that we move from our pages
> running in MTA to running in STA. We have no native COM components running
> on any of our pages, so it is frustrating to have to set this flag when all I
> want are the Intrinsics of the page.
>
> I am wondering how other people have implemented solutions where the
> presentation layer has to provide the middle tier with connection
> information. I understand that Whidbey will not support ASPCompat, so does
> anyone know if there will be a way to retrieve Session data from a com+
> component hosted on another machine?
>
> Cheers, Ian Williamson
>
>

I will try to be more concise.

We have a presentation tier hosted on a web server where all our .aspx pages
and associated code behind live. We have a middle tier which is made up of a
number of COM+ libraries. These two tiers currently reside on the same
computer, but the long term vision is to implement .NET remoting to allow the
tiers to be physically separated.

The current implementation only allows for one database to be served up.
Because of this, the middle tier is used to host the server and database name
in the registry. Our clients may have multiple databases that support the
application (test, training, production, etc). For them to change between
databases, they have to modify the registry and then cycle IIS so that the
associated caches are reloaded with the appropriate data from the newly
specified database.

We now wish to support multiple database connections. So, when a user logs
into the application, not only do they specify user name and password, they
also pick from a list of available databases (test, training, production,
etc). Since the database connection is now associated to a user, we can no
longer use the middle tier as the source of the connection properties.

Everytime data is requested, there must be some mechanism to specify which
server and database the data should be pulled from. The nasty brute force
method is to pass this information along with every call from the web page
into the middle tier. In my research, I found that you could expose the ASP
Intrinsics of a page and consume them from a serviced component.

When a user logs in, the server and database they have selected is stored to
the Session object. When a request is made from one of the pages to retrieve
data, the middle tier retrieves this Session information using the following:
ASPTypeLibrary.Session oSession =
(ASPTypeLibrary.Session)ContextUtil.GetNamedProper ty("Session");

This call utilizes the ASPTypeLibrary COM library.

For a web page to be able to expose it's Intrinsics, the property
ASPCompat="true" must be added to the Page directive. By setting this
property, the page now executes in a Single Threaded Apartment (STA) as
opposed to it's default Multi Threaded Apartment (MTA). Various articles
point to the fact that this may impact performance and cause deadlocks.

My question is, how have other people implemented solutions where they need
to specify connection properties across tiers.

Is there a simpler way of persisting my connection properties into my middle
tier? (I know almost nothing of COM+)
Is the solution I am using common?
Are the performance issues significant?
Whidbey will apparently no longer support ASPCompat, so are new methods
being established to be able to retrieve information from the caller?

Thank you.

Hi Ian

Assuming the user is using one db at a time. This can be one of the possible
ways to solve the problem

For the first session call user makes to the com+ object, asp page should
pass userid/password/dbname/sessionid to the COM object.

You should have a predefined named xml file created and stored on the
machine hosting the COM components

Now this very first call can make session root entry into an xml file like
this
<UserSession Id="UserSessionId">
<UserName>UserName</UserName>
<Password>Encrypted(UserPassword) </Password>
<UserDB>DatabaseName</UserName>
</UserSession>

Now in all your subsequent call to the object you just have to pass the
'UserSessionId' for any object call. The object will get for the user data
information from the xml files based on the supplied sessionid; based on
that object will return information from the correct database. Also the
object can return some UserAuthenticated flag(on first invocation) which can
be stored in some session variable and you can check it value before making
object calls from asp.

You can create as many entries as you want in the file also you can remove
the entry once the user logs out or his session expires.

HTH



"Ian Williamson" <> wrote in message
news:76C929A5-D999-4689-9250-...
>I will try to be more concise.
>
> We have a presentation tier hosted on a web server where all our .aspx
> pages
> and associated code behind live. We have a middle tier which is made up
> of a
> number of COM+ libraries. These two tiers currently reside on the same
> computer, but the long term vision is to implement .NET remoting to allow
> the
> tiers to be physically separated.
>
> The current implementation only allows for one database to be served up.
> Because of this, the middle tier is used to host the server and database
> name
> in the registry. Our clients may have multiple databases that support the
> application (test, training, production, etc). For them to change between
> databases, they have to modify the registry and then cycle IIS so that the
> associated caches are reloaded with the appropriate data from the newly
> specified database.
>
> We now wish to support multiple database connections. So, when a user
> logs
> into the application, not only do they specify user name and password,
> they
> also pick from a list of available databases (test, training, production,
> etc). Since the database connection is now associated to a user, we can
> no
> longer use the middle tier as the source of the connection properties.
>
> Everytime data is requested, there must be some mechanism to specify which
> server and database the data should be pulled from. The nasty brute force
> method is to pass this information along with every call from the web page
> into the middle tier. In my research, I found that you could expose the
> ASP
> Intrinsics of a page and consume them from a serviced component.
>
> When a user logs in, the server and database they have selected is stored
> to
> the Session object. When a request is made from one of the pages to
> retrieve
> data, the middle tier retrieves this Session information using the
> following:
> ASPTypeLibrary.Session oSession =
> (ASPTypeLibrary.Session)ContextUtil.GetNamedProper ty("Session");
>
> This call utilizes the ASPTypeLibrary COM library.
>
> For a web page to be able to expose it's Intrinsics, the property
> ASPCompat="true" must be added to the Page directive. By setting this
> property, the page now executes in a Single Threaded Apartment (STA) as
> opposed to it's default Multi Threaded Apartment (MTA). Various articles
> point to the fact that this may impact performance and cause deadlocks.
>
> My question is, how have other people implemented solutions where they
> need
> to specify connection properties across tiers.
>
> Is there a simpler way of persisting my connection properties into my
> middle
> tier? (I know almost nothing of COM+)
> Is the solution I am using common?
> Are the performance issues significant?
> Whidbey will apparently no longer support ASPCompat, so are new methods
> being established to be able to retrieve information from the caller?
>
> Thank you.
>

Ian:

Add a factory in the middle tier. This factory can be accessed locally or
through remoting. Use the user input selrection (test , production, etc.),
and have the factory out the connection string. The using the facade
pattern, have this hidden from the web page. The facade pattern is
everywhere and easy to find examples. Another one may be the command pattern
to consider.

"Ian Williamson" wrote:

> I will try to be more concise.
>
> We have a presentation tier hosted on a web server where all our .aspx pages
> and associated code behind live. We have a middle tier which is made up of a
> number of COM+ libraries. These two tiers currently reside on the same
> computer, but the long term vision is to implement .NET remoting to allow the
> tiers to be physically separated.
>
> The current implementation only allows for one database to be served up.
> Because of this, the middle tier is used to host the server and database name
> in the registry. Our clients may have multiple databases that support the
> application (test, training, production, etc). For them to change between
> databases, they have to modify the registry and then cycle IIS so that the
> associated caches are reloaded with the appropriate data from the newly
> specified database.
>
> We now wish to support multiple database connections. So, when a user logs
> into the application, not only do they specify user name and password, they
> also pick from a list of available databases (test, training, production,
> etc). Since the database connection is now associated to a user, we can no
> longer use the middle tier as the source of the connection properties.
>
> Everytime data is requested, there must be some mechanism to specify which
> server and database the data should be pulled from. The nasty brute force
> method is to pass this information along with every call from the web page
> into the middle tier. In my research, I found that you could expose the ASP
> Intrinsics of a page and consume them from a serviced component.
>
> When a user logs in, the server and database they have selected is stored to
> the Session object. When a request is made from one of the pages to retrieve
> data, the middle tier retrieves this Session information using the following:
> ASPTypeLibrary.Session oSession =
> (ASPTypeLibrary.Session)ContextUtil.GetNamedProper ty("Session");
>
> This call utilizes the ASPTypeLibrary COM library.
>
> For a web page to be able to expose it's Intrinsics, the property
> ASPCompat="true" must be added to the Page directive. By setting this
> property, the page now executes in a Single Threaded Apartment (STA) as
> opposed to it's default Multi Threaded Apartment (MTA). Various articles
> point to the fact that this may impact performance and cause deadlocks.
>
> My question is, how have other people implemented solutions where they need
> to specify connection properties across tiers.
>
> Is there a simpler way of persisting my connection properties into my middle
> tier? (I know almost nothing of COM+)
> Is the solution I am using common?
> Are the performance issues significant?
> Whidbey will apparently no longer support ASPCompat, so are new methods
> being established to be able to retrieve information from the caller?
>
> Thank you.
>