Front page | perl.p5ee |
Postings from October 2001
Re: P5EE Computing Platforms
October 27, 2001 13:56
Re: P5EE Computing Platforms
Message ID: 3BDB2C9B.21385.DDE473@localhost
oh, the joys of working late at the weekend....
( a little disclaimer just in case anyone thinks I make a habit of
reading mailing lists at 10:00 on a saturday night. )
On 27 Oct 2001, at 12:40, Stephen Adkins wrote:
> I propose the following definitions and computing platforms for
> the P5EE initiative. The main thing I wanted to do was propose
> the range of platforms that P5EE-compliant software should run
> on (see at bottom). Thoughts are welcome.
> The following definitions are excerpted from
> Simply put, something in the realm of computing becomes an "Enterprise"
> thing when it is worthy of and suitable for use in large enterprises.
> For the purposes of this P5EE specification, the following definitions
> will be used.
> * Enterprise System - Enterprise Software running on an Enterprise
> * Enterprise Solution - same as an Enterprise System, but emphasizing
> that the system solves an Enterprise Problem
> * Enterprise Software - Software that solves an Enterprise Problem
> (rather than a departmental one) and that is written with an
> Enterprise Software Architecture
> * Enterprise Software Architecture - A Software Architecture which
> allows software to exhibit all of the attributes of an Enterprise
> System when run on an Enterprise Platform
> * Enterprise Platform - A set of computing and networking resources
> which enable installed Enterprise Software to exhibit the full
> attributes of an Enterprise System (most often referring to
> availability, scalability, and reliability)
> The following platform descriptions are excerpted from
> The following computing platforms are defined.
> They are not all Enterprise Platforms.
> However, they are all platforms which P5EE software should run on.
> This is because P5EE software will often be developed, demonstrated,
> evaluated, or even operated initially on these platforms.
I'm Not sure I really agree that the full p5ee should run on all of
these. ( some elements of it might ).
I would have thought that p5ee would have supported both
asynchronous and synchronous activity. Quite how you would do
this with normal CGI I don't know. I could be wrong, but I always
assumed that a broken http connection would result in a termination
of the application.
To some degree I think it depends on the choice of a base
architecture. I've heard mention of CORBA and mod_perl so far.
If mod_perl were chosen, then I would have thought it more likley
that at least a two tier web serving architecture would be in place,
with one tier doing the static stuff, and another doing the perl based
( see: http://perl.apache.org/tuning/ )
Of course, two tier web serving isn't necessary, but I think it would
Perhaps a more reasonable strategy ( for a full install ) would be
root access on a single box?
> The software may be upgraded to an Enterprise Platform at any time.
> This will be one of the major advantages of the P5EE Software
> Architecture: its support for a variety of Platforms.
> Platform Overview
> * CGI only, Single System (unprivileged) - a typical ISP/web-hosting
> * CGI, Single System (unprivileged) - a typical way that a corporate
> user or university student can set up the platform without getting
> system administrators involved. This differs from the "CGI only"
> because the user also has the privilege to run daemons and schedule
> * Single User mod_perl, Single System (unprivileged) - a typical
> way a developer will do development
> * mod_perl, Single System (unprivileged) - like the "CGI, Single
> System (unprivileged)" system but higher performance and more
> * mod_perl, Single System (privileged) - a simple, entry-level
> production platform. This has only a single, mod_perl-enabled
> Apache server to handle static and dynamic requests.
> * Mirrored (unprivileged) - the closest thing to a highly-available
> system that can be set up by non-privileged users. Data is
> replicated in near-real time between a collection of machines,
> and any of the participating mirrors may be used to access the
> same applications and data. Each of the mirrors may choose to be
> implemented as one of the other platforms. This also supports the
> detachment of mirrored systems from the network (i.e. laptops)
> and later reattachment and synchronization.
> * Dual Redundant System - entry-level Enterprise platform, offering
> simple failover from the primary to the backup secondary system
> (no load-balancing)
> * Single Site Cluster - typical Enterprise platform, offering
> virtually unlimited scalability through load-balancing and
> redundancy of every computing resource
> * Multi-Site Cluster - global Enterprise platform, offering
> everything a Single-Site Cluster offers in terms of scalability,
> but with the added advantage that multiple sites dispersed
> geographically may handle regional load and guard against major
> regional catastrophes like earthquake, nuclear attack, etc.