荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: Jobs (温少), 信区: Visual
标 题: Application Configuration and Deployment with ASP
发信站: BBS 荔园晨风站 (Sun Sep 17 03:35:27 2000), 转信
Application Configuration and Deployment with ASP+
ASP+ introduces a lot of new concepts ?not just in the code, but also in
the overall framework of your applications. You can change the
configuration of your application away from the server, deploy
components without having to register them, and the global.asa file has
a new suffix and enhanced functionality. Let's start by looking at
global.asax: although it is not directly related to system
configuration, it is important to clearly distinguish it from the new
application file config.web.
Global.asax
Similar to ASP, ASP+ supports a global declarative file per application
for application events and state. Events are code sections that we can
participate in and are raised at certain points during request and
application processing. State is the collection of variable instances
and data unique to the application or browser sessions scoped within it.
Global.asax looks remarkably similar to ASP's global.asa, with the
exception of directives, new events, and its new file extension. For
example, the following code should look familiar if you've worked with
global.asa:
<script language="VB" runat=server>
Sub Session_OnStart()
' Code goes here
End Sub
Sub Session_OnEnd()
' Code goes here
End Sub
</script>
Note the difference to normal in the opening line of code.
Application code is only callable within events. Any application code
that we want run, such as when a new session instance is created, must
be run within an event, in this case Session_OnStart() event. As with
global.asa, the global.asax application file lives in an Internet
Information Server virtual root or directory, which signifies an
application in IIS. If a global.asax file exists in a directory that is
not marked as an application it is ignored.
When the first request comes in for an ASP+ application, global.asax
is compiled (similar to an ASP+ page or web service file). The
application's global.asax instance is then used to apply application
events and state for the life of each request. For example, if the web
application makes use of ASP+ sessions, the Session_OnStart() event
would be called when the session is first initiated:
Sub Session_OnStart()
' Code goes here
End Sub
Both global.asax and global.asa are files used for application code in
virtual roots or web sites in IIS. Although both of these files may
reside in the same virtual root or directory, their settings will be
applied independently of one another. What this means to you as a
developer is that you cannot share application or session state between
ASP and ASP+. Yes, your existing ASP applications will continue to work
side朾y杝ide with ASP+, but the two cannot intrinsically share ASP/ASP+
application data or events. However, global.asax can be updated 'live'
?you do not need to stop IIS.
Events make our lives as developers easier. Rather than writing if/then
blocks inline to execute code when certain behaviors occur, we can
intelligently participate in the event model provided by ASP+.
Global.asax supports more than 15 events for you to participate in. This
is a big change from ASP 3.0's global.asa, which only had minimal
Application and Session OnStart/OnEnd eventing.
Application Configuration
Developers and administrators both need ways to modify configuration
settings of a web server without needing to go through a user interface
or needing local access to the server. One of the goals for ASP+ is a
simplified configuration system whereby updates to system settings can
easily be made without the need for local system access.
ASP 3.0 Configuration Settings
Previous versions of ASP relied upon IIS settings for application
configuration information. For example, settings such as session state,
buffering, default languages, and script timeout settings are all
configured from the Application Configuration 's dialog App Options tab,
found in the application's property settings (by right clicking on an
IIS application):
These are just some of the settings that need to be configured through
the Microsoft Management Console (MMC) for application settings. All
settings or modifications are then applied to the IIS metabase, which is
used to compute application settings at runtime for the web application.
ASP+, on the other hand, does not have any reliance upon the IIS
metabase. Instead, it relies upon a declarative XML configuration file
known as config.web. Having an XML configuration file gives us several
benefits:
Copy your configuration with your code and content
Standard text and XML editors can be used to configure settings ?human
readable
It is easy to FTP to a web site and modify settings
No reboots
Config.web is an extensible configuration file that supports an open
schema others can extend. This is intended so that 3rd parties can
easily extend the programming model and use config.web for storing their
application and configuration data.
A config.web file may exist in any directory, and settings declared
within config.web are applied to all interactions with resources in that
directory and its children; unless a child directory also contains a
config.web file, in which case a union of the settings are applied with
the priority going to the child settings.
Since config.web is an XML file, we expect it to have a root node.
Config.web 's root node is <configuration>, and within <configuration>
there are two tag types, which are used to define the various config.web
settings:
<configuration>
<configsections>
[config section handlers]
</configsections>
[config section settings]
</configuration>
In the above config.web example [Configuration Section Handlers]
identifies .NET classes that handle configuration settings. The
[Configuration Section Settings] then specifies the settings to apply.
This is quite a powerful and flexible model since config.web relies upon
the named (<configsections>) classes to be responsible for understanding
the various settings.
Deployment
Deployment of web applications today can be somewhat difficult,
especially in large web server farms when local machine access is
required to make changes. For example, here are some tasks most
developers will perform when deploying an application:
IIS Metabase Changes ?Changes to the number of ScriptEngineCaches,
modification of session state, or changes to the way pages are
authenticated, e.g. NTLM or Basic.
Security ?Changing the authorization aspect of a page requires server
access to modify the Access Control List on file resources. This can be
especially painful on large server farms.
COM and COM+ Component Registration/Updates ?Objects require
registration in the registry to provide mechanisms for discovery. The
command line tool regsvr32.exe is used to register new components, but
it must be used on the local machine. In addition, when a particular
object must be updated, the potential exists for both COM and IIS to
'pin' or 'lock' the associated .dll to a process. This translates to
system administrators having to stop the IIS service, deregister the
component, register the new component, and restart the service.
These types of headaches have gone away with ASP+.
One of the goals of ASP+ is to make deployment of web applications a
simple matter of copying a file tree to a new location and 'it just
works'. This is true of all ASP+ application details: web pages, web
services, config.web, global.asax, assemblies, etc. There are no
administration or registration tools (such as regsvr32) to register
objects. Assemblies contain their own metadata (object description
information), and simply dropping them in the \bin directory of the
application suffices for the assembly to be available to the
application. The \bin directory is a special directory in an ASP+
application where assemblies are 'registered'.
Since the \bin directory is relied upon as part of an application, it
follows the same rules as global.asax. It must be located within an IIS
web application. This includes both IIS web roots and virtual
directories:
In the above screenshot the \bin directory exists within the Preview IIS
web root. Any assemblies found within, such as Math.dll, ServerVars.dll,
and Stock.dll are available to the entire Preview web application. Each
web application assembly, such as Math.dll from our screenshot above, is
isolated from other web applications. For example, our web service
Math.dll is available only within the scope of the Preview web
application. Other web roots such as Default Web Site and Administration
Web Site do not have access to Math.dll.
Thus, assemblies can be private to the application (since each contains
its own \bin directory). Other applications cannot load private
assemblies or classes. This means that other applications can use
different versions of the same objects without collisions on the system.
In addition to no regsvr32 registration, there is no regsrv32 for
deregistration. No entries are made into the Windows registry, thus when
you delete an assembly it is completely removed from the system. In fact
the entire application supports this delete to uninstall philosophy,
making the task of administering a web server very easy.
ASP+ is smart enough to detect changes to the system and will serve new
requests on the updated files as it spins down existing requests on the
replaced files. This allows us to copy assembly .dll files over existing
assembly .dll files in a running application ?even when the assembly is
being used. When an update is made to the \bin file this signals the
ASP+ system to service all new requests on the new assembly, but compete
all existing request on the existing assembly. The application never
needs to be stopped and started, and is always available to the end
user.
Compatibility with ASP
ASP+ assemblies and services can be made to be backwards compatible with
ASP, but in this case the components will still require to be registered
and there will be a housekeeping overhead as a Runtime Callable Wrapper
representing the ASP component is copied to the \bin directory. ASP+
components can also be used with ASP ?in this instance a Com Callable
Wrapper and registration via RegAsm.exe is required.
Conclusion
ASP+ is designed to allow configuration of your application even when
accessing away from your server, and the xml config.web file holding the
configuration settings is designed to be human readable. You can also
install and delete components without requiring to register or
deregister them ?a welcome improvement over ASP!
--
好好学习，天天向上！！！！
※ 来源:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 192.168.18.211]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店