The most important advance that object-orientation and component architectures have brought to software is the ability to effectively separate business logic from the machinery of applications. Like people, all systems eventually must die. Upon demise, the syntax of the code and the context of the operations become outmoded and relatively unimportant. The mechanics of massaging data will always be part of new software paradigms, and haven't really changed significantly for many years. What remains important to the enterprise is the underlying data and those logical relationships between data points that represent the invaluable commodity we call information. By and large, the smart people in software are centralizing these assets into models that can be transferred from environment to environment without serious dependencies on the languages or tools that were originally used. This is the state of the art, light years from the procedural focus of yesterday.
There is a mantra of engineering and management called "the 80/20 rule" that I've seen demonstrated repeatedly in most every field of endeavor, even software. It postulates that for a given problem space, you can meet 80% of the needs with 20% of the effort it would take to solve everything. Modern component architectures like .Net and J2EE seek to be all things software for a networked enterprise. While they are certainly powerful, they bring with them an enormous amount of complexity, thereby increasing overall cost beyond the reach of many small businesses. They are being steered by proprietary players that don't always have the customers' interests at heart. Besides, ultimately they still aren't the silver bullet that delivers an elegant solution for every situation. Through refinement and competition, these platforms will continue to provide developers with a lot of useful abstractions that can serve as blueprints and best practices, but as a Perl programmer I know...
There's more than one way to do it!
The LDAPHttp Framework is an architecture that I believe embodies an 80/20 solution for dynamic, transactive, and portal web applications and services. It effectively defines a clear separation of business logic from details of procedure and presentation. The required platform has only three major pieces to administer: a web server, a servlet container, and a directory server. Each of these is simple and familiar, based on time-tested open standards and available from a variety of vendors. You could even download and install quality free and open source implementations for all three today. They are designed for internet communication, can be arranged in several distributed topologies, and have trusted methods for implementing security. Together they represent a very strict subset of what's already required by the larger component architectures mentioned above, so the LDAPHttp Framework can serve as an entry point into modern enterprise development if not just an end in itself.
The software that glues all of it together is free, open source, production quality, and tight. In fact, the current Java archive file of compiled code for the LDAPHttp Framework *and* the Gateway application currently weighs in at less than 150K(!). The fundamentals were developed first; there are plenty of enhancements planned for the short term but none of them jeopardize the existing design. Perhaps most important, the framework is non-exclusionary and fully extensible, so if it doesn't integrate with the tools you use or do all the things you want, there is nothing stopping you from adding the necessary hooks, overriding the appropriate behaviors, or using the classes in unanticipated ways. Unlike proprietary vendors, I'll actually encourage it.
So what about the other 20% of your software needs? Like every other solution, the LDAPHttp Framework is not the best tool for all situations. While the use of relational databases is not precluded, the assumption is that you would use an LDAP-compliant directory database to store your data. As a result, you lose some of the power of SQL and a few high-end RDBMS features in exchange for simplicity and a lower cost. In particular, it would be inappropriate to use this software to build data warehouses where you want to drill around or financial applications that require lots of number crunching. LDAP has traditionally been used for central authentication or address book applications, but as developers worldwide explore this protocol's abiding merits, its utility is starting to expand far beyond original intent.
The chief advantages of the LDAPHttp Framework are that it's open, lightweight, cheap to implement, easy to administer, flexible to develop to, identity inclusive, and object-oriented end to end. The sweet spot for LDAPHttp would be web sites that serve large amounts of categorical information and allow interaction with anonymous or defined users. Go ahead and think big. Think Amazon. Think Yahoo. Think of an intranet presence spewing monster amounts of real time information in various XML formats compiled from directory databases distributed across an array of low-cost servers. Whatever. Most importantly, though, think return on investment. That remaining 80% effort is just not in the budget for these days and should be considered an absolute waste if your systems never really required it in the first place.
Design | Javadocs | Downloads | Examples | Plan
Services | Products | Standards | Vision