P5EE - Frequently Asked Questions

1. What qualifies as an enterprise system? - See http://www.officevision.com/pub/p5ee/definitions.html.
2. When should I not design for an enterprise system? -
   • Every requirement costs development time and money to satisfy. Know your requirements and don't overbuild.
   • Most frameworks on which you might build an application support a variety of deployment platforms, each of which satisfy different requirements.
   • A little forethought can save a lot of rework. It would be nice to choose a framework which would enable the proposed software to be deployed on a platform the supports the current requirements today and the maximum envisioned requirements when they arise.
   • You should understand both your current requirements and your maximum envisioned requirements.
3. Why should we develop an enterprise system in perl ? Advantages / disadvantages of it over other systems. (considering rapid development, flexibility, performance, scalability, fault tolerance, etc.) -
   It's important to understand the current niche (or "sweet spot") of a language, its tools, and its community.
   • .NET - Microsoft-oriented development and deployment
   • Java - Corporate, open-systems enterprise development
   • PHP - Small web applications and Free Software web applications (accompanied by perl scripts for server-side processing
   • Perl - Server-side data processing and small web applications (with business logic shared between the two)
   • Lesser-used languages (Python, Ruby, etc.) - Server-side experimentation and small rapidly-developed web applications
   This is not to say that these languages can not be used outside of their current niche.
   Perl is a great language with every bit as much capability as Java and many features I prefer.
   A truly enterprise-worthy language needs language capabilities, framework/platform/tool support, and a supporting community.
   The reason that I wanted to start the P5EE project was to work on the framework/platform/tool support and the supporting community (including the pool of available developers).
   Java is the (non-Microsoft) corporate world's choice for enterprise system development.
   The only reason to choose perl is if you have a good answer for the framework/platform/tool and community issues.
4. Design considerations (what, how and why) when building up an enterprise system
   • performance - mod_perl/mod_parrot, clustering and proxying, memory management, caching
   • scalability - hot spots, session management
   • fault tolerance - which faults?
     • fault tolerance requires an application-to-motherboard analysis of possible fault conditions and required application behavior
     • analysis should include planned maintenance actions
     • the easiest faults to envision involve total system failure, detectable by an inability to connect
     • database fault tolerance - depends largely on underlying database software. can be supplemented with supporting logic in a database access layer. attention must be paid to transactions.
     • web server fault tolerance - clustering/load-balancing solves most problems. session management strategy is central to whether a given solution will work.
5. Service oriented Architectures, why, how, when and when not -
   • "SOA" requires definition. A Service-Oriented Architecture (SOA) is one where major application components are exposed for use by other applications within an enterprise's computing realm.
   • Should always be a consideration. It's a matter of reuse and leverage.
   • Implement when needed. Be aware of additional policy/governance issues.
   • The framework you build or build upon should support it.
   • SOAP should be seen as just one binding in an SOA.
6. Different approaches (your experience) in identifying bottlenecks in an application -
   • Four system-level bottlenecks: CPU, memory, disk, network
   • Application-level bottlenecks: process/threading models, planned application flow, application/db locking, IPC blocking
   • Must have appropriate application logging hooks to diagnose
   • timings for application phases
   • timings and classifications for db queries
   • Performance monitoring and analysis (for both app and database) should be a part of operations
   • Performance improvement should be a part of planned maintenance and a separate thread of activity
7. Different approaches to caching for an application -
   • reading/writing an expensive data store (i.e. the database)
   • Application-level bottlenecks: process/threading models, planned application flow, application/db locking, IPC blocking
   • Must have appropriate application logging hooks to diagnose
   • timings for application phases
   • timings and classifications for db queries
   • Performance monitoring and analysis (for both app and database) should be a part of operations
   • Performance improvement should be a part of planned maintenance and a separate thread of activity
8. Different approaches to reduce the memory footprint of an application (say a file parser), Trade offs -
   • Don't be afraid to use the memory.
9. Regex optimization, techniques, debugging approaches -
   • Don't use /.*?/. Use things like /[^"<>]*/ instead.
10. Philosophy of Perl 6 - I can't say this much more elegantly than has already been done.
    • http://dev.perl.org/perl6/
    • http://dev.perl.org/perl6/faq.html
    My opinions and predictions about Perl 6 are these.
    • Perl 6 is going to be big... like Apache 2 was big.
    • The old version will stay around for a long time while people gradually migrate to the new version.
    • It will not obsolete the old version immediately.
    • There is no rush to learn Perl 6.
    • Learn the features of Perl 6 which will drive adoption, and you will know when to move up to Perl 6.
    • It will take 10 years for 80% of new Perl development to be done in Perl 6.
    • Even then, 70% of the installed base of Perl code will still be Perl 5.
    • With Perl 6, its flexibility as a scripting language will be fully complemented with its feature-completeness as a systems development language.
    • Perl 6 is every bit as much about the Parrot runtime (and Javascript runtime) as about Perl 6 itself.
    • Parrot will one day be the flagship Virtual Machine for dynamic languages (Perl, PHP, Python, Ruby, etc.)
    • Parrot will help the family of dynamic, Free languages to combine efforts (mod_parrot, DB access, etc.)