On Wed, May 15, 2002 at 09:07:17AM -0600, Rob Nagler wrote: > 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.
That is a really good point. Fortunately there are still several problems out there, and Stephen is propably solving one he has to deal with. But this might not apply to the people that look into P5EE and get disappointed that it did not solve their enterprise problems. > > 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? Or running components are partitioned from each other... > > > * 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? I'd like to add: -how do you access services or objects in your environment conveniently from Perl with its limited possibilities/guarantees ? -how do you help developers ? support for some kind of formal specification? how to set up complex behaviours without producing a lot of or unreadable code ? > > 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. > [snip...] > > 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. Isn't it rather featureritis than architecturitis ? People who read P5EE might expect something as big as J2EE. Which is way too big for the working power P5EE might attract. But we can try to address some of the problems one will have when developing enterprise-class systems or P5EE-class projects. These are very basic problems, but they actually solve real world problems or improve development and software quality. Perl is cool and I really like it, but where is the powerful and easy to use type system. Has anyone seen bigger multi-threaded perl programs? Can one keep away from the quick hack / one-liner flavour often found? For example Java (I'm no java expert at all so this is just meant to illustrate it). When it started there were several design flaws, and they are trying to remove them now, and they have a lot of man power and all that stuff. But there are still techniques/frameworks/languages/... that solve several things a lot better. We cannot compete on the feature side. But we can try to build a better core, use new and better methods of software engineering etc. If the system is supposed to heal itself, it must know a lot more about itself. Its architecture, relationships between components, guarantees, ... When we can get this information out of the code and informal guarantees into some manageable pool and things can be decided/determined with help of this information, than we can really do something better. And as one can do a lot more new/unexpected things in Perl as in other languages, this could really be a key to bringing one-liner easiness and proper software engineering together. At least that is the direction of my SE dreams :) It won't be reached, but we could try to improve things into this direction. Torvald
