473,246 Members | 1,309 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,246 software developers and data experts.

Retrieving state information from a middle tier

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
Nov 19 '05 #1
6 2206
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 Wi********@discussions.microsoft.com> wrote in message
news:D8**********************************@microsof t.com... 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

Nov 19 '05 #2
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 Wi********@discussions.microsoft.com> wrote in message
news:D8**********************************@microsof t.com...
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

Nov 19 '05 #3
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

Nov 19 '05 #4
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.

Nov 19 '05 #5
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" <Ia***********@discussions.microsoft.com> wrote in message
news:76**********************************@microsof t.com...
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.

Nov 19 '05 #6
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.

Nov 19 '05 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
by: Kumar Saurabh | last post by:
Hi Devs, I was thinking of implementing a middle tire (most probably in XML) for a PHP MySQL web app but couldn't make a head way. can any one suggest how can i proceed with this. Thanks in...
62
by: SAN3141 | last post by:
There doesn't seem to be consensus about when to put code in the database or in the middle tier. There was a long discussion about this in an Oracle newsgroup (message ID:...
2
by: billym | last post by:
Does anyone know if C# (or .NET applications in general) can be load balanced on the middle tier simply by deploying them to multiple servers in a clustered environtment? If so, would this be...
0
by: JasonP | last post by:
Hi, I am trying to decide the best middle tier method for the system I am currently building. There are no issues of supporting previous software versions, etc as this is a completely new...
8
by: Leon | last post by:
I know that I can access session state on an asp.net page using Page objects, but how do I access store data in sessionstate from the middle tiers?
1
by: dgk | last post by:
How can I create a middle tier object using the standard databinding stuff? All the examples that I see in the books using the new 2005 controls just shows how to build stuff in two tiers. It...
3
by: Jules | last post by:
Sorry for being contentious title, but I am confused and concerned over the level of MS infrastructure support to the business logic layer. MS have great support to Web services, for EAI and B2B...
0
bmallett
by: bmallett | last post by:
First off, i would like to thank everyone for any and all help with this. That being said, I am having a problem retrieving/posting my dynamic form data. I have a form that has multiple options...
3
by: SevDer | last post by:
Hello All, For my ASP.NET application, I am trying to have my middle tier (currently logical layer) dll's to be loaded dynamically. The aim is not to kill the sessions when I need to update...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.