Sorry, this isn't what you want to hear...
If you want to gain acceptance in the "enterprise", solve a problem
for them. CORBA, with all its backing, failed to succeed as well as
Java and .NET. It takes people with vested interests and power/money
to make things happen.
Let me give you a personal practical example. I'm sitting on a
Java/XML framework with a complete content management, skins, RDF/RSS,
etc. The guy who built it spent 20 years working for Tandem
Computers. He was a genius in architecture, implementation, and
marketing speak.
He's dead, and I have the responsibility of trying to give it away.
He had tried to sell it for over a year. He had very, very high-level
contacts. Everybody I've spoken to won't take it even for free.
Unfortunately, I'm too tied up to devote any energy to it.
The fundamental problem was that he failed to solve a problem with it.
Until you do, no one will believe you. You might get lucky, but I
doubt it. There is too much fear and greed in enterprises and
elsewhere.
On to the specifics...
Stephen Adkins writes:
> II. Architectural Principles
My experience selling Perl to the Architecture Astronauts tells me you
need a more compelling argument than simply motherhood and apple pie.
All "modern" architectures agree with these principles. What
differentiates your product from J2EE, Enhydra, 724 Solutions, and a
whole host of other architectures.
> III. Core Services
> * Context - abstracts all of the details of the runtime environment
> so that the same application can be deployed in a CGI Context,
> a mod_perl Context, or even FastCGI/PPerl/etc.
CGI is old. Anybody that has deployed CGI in enterprise environment
will not be able to integrate with this platform. They have already
solved that problem.
> * Config - configuration data may be stored anywhere,
And what happens to the system when "anywhere" is partitioned from the
rest of the network?
> * Session - All runtime data is stored in the Session object,
Sessions do not scale. Take a look at all the standard transaction
managers. They don't have sessions. Well, they do now, but only
because of poorly design application runtimes like CGI. Here are the
problems with sessions:
1) They complicate load balancing if you store the sessions
locally in the server. OR, they create another bottleneck if you
store the sessions centrally.
2) Sessions denormalize data.
3) Sessions are a pre-optimization, and "Pre-optimization is the root
of all evil."
4) Sessions create security risks (probably a side effect of
denormalization).
5) Sessions create a distributed garbage collection problem.
The fundamental principle is:
Someone famous once said, "every software problem can be solved with
another layer of indirection."
Someone I work with (Martin Lichtin) said, "every layer of indirection
creates a new software problem.
Don't make sessions a core service. In fact, avoid configuration as a
core service. Instead tackle the hard problems:
1) Transaction Management: how do you coordinate transactions email,
dbs, 3rd party services (ec gateways), and file systems? You need
to prioritize distributed rollback/commit.
2) Naming: how do you get to the foobar service?
3) Process Management: how to start, upgrade/downgrade, stop the
services? Solve the problem upgrading 1000 machines or *not*.
Hint: use core services 1 & 2.
4) Monitoring/self-healing: how do you know when something is wrong?
How do you fix it? Hint: you need core service 3.
5) Security: who has access to what data and actions?
BTW, you need to make this work across multiple platforms, multiple
languages, multiple admin domains, and multiple application
frameworks. It won't sell today without a GUI.
> perlinc = /usr/ov/acoc/dev/src/P5EEx-Blue,
> /usr/ov/acoc/dev/lib/perl5/5.6.0
> debugmode = record
> showsession = 1
> gzip = 1
> configFile = demo.pl
> defaultWname = report
> debug = 0
> debugfile = debug.out
> scriptUrlDir = /cgi-bin/pub/p5ee
> scriptDir = /usr/ov/acoc/dev/p5ee/P5EEx/Blue/cgi-bin
> htmlUrlDir = /pub/p5ee/software/htdocs
> htmlDir = /usr/ov/acoc/dev/p5ee/P5EEx/Blue/htdocs
> ttTemplateDir = /usr/ov/acoc/dev/p5ee/P5EEx/Blue/template/ttdemo
Minor comment. Don't invent your own languages. Don't hardwire
paths. Don't repeat yourself.
> $data = {
> #########################################################################
> # $Id: demo.pl,v 1.3 2002/04/19 14:38:44 spadkins Exp $
> # NOTE: this is after the "$data = {" line for a reason
> #########################################################################
> WidgetType => {
> table => {
> widgetClass => 'P5EEx::Blue::Widget::HTML::DataTable',
> repository => 'db',
> table => 'person',
> headings => [ "ID", "Last Name", "First Name", "Address", "City",
> "State", "Home Phone", "Sex", "Birth Date" ],
> columns => [ "person_id", "last_name", "first_name", "address",
> "city", "state", "home_phone", "gender", "birth_dt" ],
> keycolidx => [ 0 ],
> scrollable => 1,
> sortable => 1,
> filterable => 1,
> editable => 1,
> },
> app => {
> widgetClass => 'P5EEx::Blue::Widget::HTML::AppFrame',
> title => "P5EE Reporting and Data Maintenance",
> bgcolor => "#cccccc",
> text => "#000000",
> link => "#996600",
> vlink => "#996600",
> alink => "#996600",
> leftmargin => "0",
> topmargin => "0",
> rightmargin => "0",
> bottommargin => "0",
> },
> },
> Repository => {
> default => {
> repositoryClass => 'P5EEx::Blue::Repository::DBI',
> dbidriver => "mysql",
> dbname => "p5ee_demo",
> dbuser => "dbuser",
> dbpass => "dbuser7",
> table => {
> person => {
> prikey => [ "person_id" ],
> },
> },
> },
> },
> Widget => {
> report => {
> widgetType => 'app',
> },
> 'report.selector' => {
> widgetClass => 'P5EEx::Blue::Widget::HTML::SelectorView',
> selected => "1.1",
> node => {
> 1 => { open => 1, value => 'Reports',
> icon => 'calendar.gif' },
> 1.1 => { open => 1, value => 'People', wname =>
> 'table', },
> },
> },
> table => { widgetType => 'table', },
> },
> };
Reread the preface to Programming Perl 3rd ed. It says something like:
All programming languages allow hard problems to be solved. It's what
they make easy that differentiates them. Why do I need all this
configuration? Why do I need to repeat myself so much? Why do I mix
passwords and colors in the same file? How do I share parts of the
configuration and not others?
Start with a problem. Do the simplest saying that could possibly
work. Don't implement anything you don't need today. Remove unused
function as soon as it is unneeded. Don't deprecate, delete. Repeat
until problem is solved. Now, go solve another problem. After five
problems, you may have an enterprise class system, but only if the
previous five solutions have been installed in enterprises.
If enterprise frameworks were as easy as one guy going off and hacking
for a couple of months, my dead friend's system would have sold
millions. It didn't. It's a hard lesson. It's one my friend failed
to learn. I'm just beginning to learn it. Fortunately, I have people
around me who keep my architecturitis from infecting them and the
project.
Rob
