Retrieving state information from a middle tier

Discussion in 'ASP .Net' started by =?Utf-8?B?SWFuIFdpbGxpYW1zb24=?=, Feb 25, 2005.

  1. 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
    =?Utf-8?B?SWFuIFdpbGxpYW1zb24=?=, Feb 25, 2005
    #1
    1. Advertising

  2. 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
    news:D...
    > 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
    >
    >
    Kevin Spencer, Feb 25, 2005
    #2
    1. Advertising

  3. =?Utf-8?B?SWFuIFdpbGxpYW1zb24=?=

    Vaibhav Guest

    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
    news:D...
    > 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
    >
    >
    Vaibhav, Feb 25, 2005
    #3
  4. 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
    >
    >
    =?Utf-8?B?aW5ldG11Zw==?=, Feb 25, 2005
    #4
  5. 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.GetNamedProperty("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.
    =?Utf-8?B?SWFuIFdpbGxpYW1zb24=?=, Feb 25, 2005
    #5
  6. =?Utf-8?B?SWFuIFdpbGxpYW1zb24=?=

    Vaibhav Guest

    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:...
    >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.GetNamedProperty("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.
    >
    Vaibhav, Feb 25, 2005
    #6
  7. 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.GetNamedProperty("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.
    >
    =?Utf-8?B?aW5ldG11Zw==?=, Feb 25, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Craig Buchanan

    Middle-tier equivalent to server.mappath?

    Craig Buchanan, Jan 26, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    1,572
    martin
    Jan 27, 2004
  2. Guadala Harry

    ADO.NET DataReaders and the Middle Tier

    Guadala Harry, Feb 21, 2004, in forum: ASP .Net
    Replies:
    7
    Views:
    785
    Guadala Harry
    Feb 21, 2004
  3. Joe
    Replies:
    71
    Views:
    1,395
    JEDIDIAH
    Jun 24, 2004
  4. keith edward
    Replies:
    1
    Views:
    340
    Abrasive Sponge
    Sep 23, 2004
  5. John
    Replies:
    7
    Views:
    1,011
    Alex Hunsley
    Apr 7, 2006
Loading...

Share This Page