 
 |
Storage Networking , Part 1
eBook: A storage network is any network that's designed to transport block-level storage protocols. But understanding the ins and outs of networked storage takes you deep into several of protocols. This guide covers SANs, Fibre Channels, Disk Arrays, Fabric, and IP Storage.
»
Storage Networking 2, Configuration and Planning
eBook: Picking up where Part 1 left off, Part 2 of our look at storage networking examines configurations for SAN-attached servers and disk arrays, and also includes a look at the future of IP storage.
»
Storage Management Costs in the Enterprise: A Comparison of Mid-Range Array Solutions
Whitepaper:
Many factors contribute to the ownership cost for enterprise storage. These include (but are not limited to): physical capacity relative to physical space requirements, performance capacity for data transfer and system reaction time, software maintenance and updates, expandability and flexibility, and much more.
»
Storage Is Changing Fast Be Ready or Be Left Behind
PDF: The storage landscape is headed for dramatic change, thanks to new technologies like Fibre Channel over Ethernet (FCoE), pNFS, object-based storage and SAS that will affect everything from NAS and SANs to disk drives. Get the knowledge you need to make the most of your storage environment, now and in the future.
»
HP StorageWorks EVA4400
Demo:
Dont settle for an expensive and complex array that lacks functionality. The HP StorageWorks EVA4400 delivers virtual storage with enterprise class functionality at an affordable price.
»
|
|
|
|
|
|
The Existing Perl Modules
January 25, 1999
Soon after the release of
Perl 5,
the community was blessed
with a flood of excellent objects (Perl Modules) that
could be used in support of web-based applications. Among
these modules were the
CGI,
LWP and
DBI modules.
The
CGI module
takes care of organizing form name/value
pairs and
HTML
output, as well as other useful features such
as file uploading, error handling, and manipulation of the
environment variables.
The
LWP (Library for Web Programming) module made networking simple.
A standard API
could be utilized to make your stand-alone CGI
application networked with all the services available to
any HTTP client including FTP, GOPHER ,HTTP, local files,
and HTTPS (SSL) connections.
Finally, the
DBI module
gives your CGI application access to
almost any commercial, shareware, or freeware
database that is used in support of
web applications. Without knowing
anything about database technology, a developer can use the
simple interface to access and manipulate the most complex
of databases. Further, since the
DBI module was an interface,
if the backend database suddenly was changed from one database
to another such as from Oracle to Sybase,
no modification would be necessary in the client code. You would
just need to import a different DBD (Database Dependent) module.
We will cover more regarding interface modules a little later.
Proposed Extropia Extensions
The CGI, LWP, and
DBI modules are all fantastic tools for
web-application development. However, they are not enough.
In fact, for the most part, these three modules are more useful
at a deep infrastructure level. Most real-world application code
deals with higher order issues.
With 5 years of experience designing generic, open source
applications behind us, we are in a unique position
to know what other black boxes must be developed for truly
efficient web application development. In addition, because
of the valuable feedback of over 5 years of gathering users
and developer ideas from all types of businesses, we are
able to leverage that knowledge in creating a framework
that is likely to be extensible to any type of business these
components will be used in.
Coding of several modules began in November 1998 and will
continue thru December 1998 with expected release dates
in January 1999.
The new modules include:
Extropia Modules
DataSource
FlatFile
DBI
HTTP
CGI
FTP
FileSystem
DBM
XML
Mail
SendMail
SMTP
Blat
Postie
Encryption
PGP
Crypt
MD5
Authentication
Server
CGI
Session
Cookie
HiddenField
Search
Dynamic
Indexed
DataValidation
Application
All of these modules take advantage of the concept of "interfaces".
|
It is especially important to note that not all these modules will
be written by us. The
Comprehensive Perl Archive Network
(CPAN) contains a rich set of modules. Where applicable, we
will be interfacing with these modules rather than building our own
entirely from scratch.
|
Interfaces
An interface presents a single
independent
API
to client code yet has the ability
to dynamically call dependent backend code depending on
what the client code asks for. This is a little bit hard to
see without an example, so let's look at how the
DBI module
implements the interface architecture.
The
DBI interface provides a single database connectivity
API
but no database connectivity implementation code. Instead, it
relies on a library of DBD (database dependent driver) modules to
implement the connection. Thus, the hierarchy of code looks
like:
Client Code ---> DBI --> DBD (Oracle)
--> DBD (Sybase)
--> DBD (Postgres)
When implemented this way, you can see that regardless of what
backend database package is being used, the Client Code remains the
same. The client code need only talk to the standard
DBI
API.
The
DBI module relies on the DBD modules for the implementation of the
requests. What is more, to add a new backend database, the user need
only code a new DBD module and add it to the list of other DBDs.
Client Code ---> DBI --> DBD (Oracle)
--> DBD (Sybase)
--> DBD (Postgres)
--> DBD (New Database)
The benefit to the user is that she need only know the
DBI
API
in order to access the myriad of DBD support modules.
Furthermore, anyone who writes a DBD module can make it
available to everyone without forcing them to modify
their code in any way.
Moving to Object Oriented Design with Perl 5 and Java Servlets
Extropia WebWare Suite 2.0: Towards a New Application Development Framework for Server-Side Web-Based Applications in Perl and Java
The Existing Perl Modules (Cont.)
|
