[Technology Report]
Working Within The Framework
A solid software framework builds in more flexibility for designers, relieving them of otherwise time-consuming tasks.
Writing an application completely from scratch is a royal pain. So, most developers turn to libraries and more sophisticated software frameworks to provide services that would otherwise gobble up precious time to develop and integrate. Frameworks can be narrowly focused, such as a graphical interface like the GIMP Toolkit (GTK+). Or they can encompass a wide variety of services, like Microsoft's .NET Framework or Sun Microsystem's Java 2 Enterprise Edition (J2EE).
A top-down view of a framework—also known as a platform, configuration, or profile—inevitably consists of dozens of boxes containing various features and applications linked through a rat's nest of connections. Choosing one or more frameworks for a project usually is as important as choosing a processor, development environment, or operating system.
In fact, all of these components can be so tightly related, the number of combinations may be limited to one. For example, Microsoft's .NET Framework runs only on Windows platforms. The primary development tool tends to be Microsoft's Visual Studio, but a number of alternatives do exist.
Likewise, frameworks with similar features and common target audiences often are available from a variety of sources. For instance, the open-source LAMP (Linux, Apache, MySQL, PHP) framework (Fig. 1) competes with solutions based on J2EE (Fig. 2) and .NET (Fig. 3).
WEB FRAMEWORKS: Much of the confusion regarding frameworks centers on the vague definitions of their capabilities. All-encompassing tags like Microsoft's .NET and Sun's Java often attempt to bring a number of frameworks together into a larger framework instead of using a functional combination such as LAMP. Unfortunately, most developers tend to work in only one part of these larger environments.
Just imagine a developer of embedded mobile devices who could use one of the two popular client-client frameworks: Microsoft's .NET Compact Framework or Java 2 Micro Edition (J2ME) with Connected Limited Device Configuration (CLDC). These client-side frameworks tend to implement fat clients, also called smart clients.
The big question is what the underlying requirements are for these kinds of frameworks. For example, the .NET Compact Framework also sets the operating system selection in stone, which isn't the case with J2ME.
Of course, moving toward thin clients emphasizes the server. AWeb browser simply provides the rendering and basic user interface. This has popularized client-side scripting languages like JavaScript, leading to a middle alternative called AJAX (for Asynchronous JavaScript and XML, or Extensible Markup Language). AJAX is currently more of a technique than a formalized framework, but it has the latest buzz.
An AJAX client application is a Web page with embedded JavaScript that's run in a Web browser when viewing the page. The client exchanges information with a host using XML-formatted messages instead of the more conventional technique of posting data to the server using HTTP and getting back a completely new Web page. An AJAX application merely exchanges messages and updates the user interface.
The big problem with AJAX is Web browser and server compatibility. Web browsers tend to be wonderfully incompatible with each other. Even different versions from the same vendor can be incompatible.
This makes it difficult for a developer to write a program to handle a wide range of browsers. It's not a new problem. Rendering the same page using different browsers often results in different views. But AJAX makes the problem much worse.
In the meantime, the more conventional-server-side implementations tend to be built on frameworks like .NET, LAMP, and J2EE. They use industry protocols such as Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL).
Frameworks like the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) are more robust than the Web-only solutions. That's due mainly to the OMG standard, which specifies both the client and server support.
CORBA is a binary communication standard, unlike the text-oriented Web alternatives. CORBA-based applications can be used to build the same kind of Web-based applications. The client typically runs a dedicated application, not a Web browser.
CORBA fits more in non-user interface applications, providing the underlying communication between distributed applications. It supports high-availability (HA) features. Still, other HA frameworks are available.
Reprints
