eXtropia: the open web technology company
Technology | Support | Tutorials | Development | About Us | Users | Contact Us
 ::   Tutorials
 ::   Presentations
Perl & CGI tutorials
 ::   Intro to Perl/CGI and HTML Forms
 ::   Intro to Windows Perl
 ::   Intro to Perl 5
 ::   Intro to Perl
 ::   Intro to Perl Taint mode
 ::   Sherlock Holmes and the Case of the Broken CGI Script
 ::   Writing COM Components in Perl

Java tutorials
 ::   Intro to Java
 ::   Cross Browser Java

Misc technical tutorials
 ::   Intro to The Web Application Development Environment
 ::   Introduction to XML
 ::   Intro to Web Design
 ::   Intro to Web Security
 ::   Databases for Web Developers
 ::   UNIX for Web Developers
 ::   Intro to Adobe Photoshop
 ::   Web Programming 101
 ::   Introduction to Microsoft DNA

Misc non-technical tutorials
 ::   Misc Technopreneurship Docs
 ::   What is a Webmaster?
 ::   What is the open source business model?
 ::   Technical writing
 ::   Small and mid-sized businesses on the Web

Offsite tutorials
 ::   ISAPI Perl Primer
 ::   Serving up web server basics
 ::   Introduction to Java (Parts 1 and 2) in Slovak


Introduction to Microsoft DNA
Collaborative Business Systems  
Previous Page | Next Page | Table of Contents

In a collaborative business systems applicaiton developers could muc more closely approach the three application layers.

Additionally each layer could be supplanted with 'proxy' layers that provide a cushion for processing, migration and scaling issues. Such an example would be a generic data source access wrapper to enable the database to be substituted without large and costly redevelopment.

With the popularization of the internet/intranet/extranet solution a gamut of problems could be addressed in a consistent manner, while at the same time enabling the holy grail of "layer separation" to move closer.

In breaking the approach into layers it becomes possible to focus on solving domain specific issues. At the same time, design flexibility could be introduced. Here's why,

  • Using a browser to access services assures a familiar lightweight interface.
  • The browser and HTML provide a standard implementation and deployment approach. Applications aren't really deployed; more borrowed.
  • No client-side issues (ignore cross browser issues for now).
  • Highly tailored solutions. Users are not required to "USE" everything.
  • Applications can be seamlessly divided across logical and physical locations.
  • Disconnected or Just-In-Time (JIT) operation.
  • Protection for both resources and clients. Fewer concurrent accesses, less resource usage.
  • Platform independent...nearly.

For example, a simple global telephone directory becomes an application that can be accessed from virtually any computer - the architecture doesn't place limits on the type of hardware, operating system, or whatever.

Previous Page | Next Page | Table of Contents