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.
HIGH-AVAILABILITY FRAMEWORKS: Interprocess communication is key to HA, but HA frameworks tend to incorporate much more. Enea's Element includes upgrade management, event logging, provisioning, accounting, and shelf management (Fig. 4). Linux vendors such as MontaVista deliver Commercial Grade Linux, an HA version of Linux.
It's easy to see how a framework like HA impacts the design and implementation of applications. Some of the features, such as shelf management and upgrades, typically have little impact on the overall application design. But features like check-pointing, load leveling, and fault tolerance require the application's active participation.
There are two reasons why a framework with these kinds of tight ties to the application must be chosen carefully. First, application developers must know the intimate details of the framework for applications to coexist and take advantage of the framework. Second, once selected and implemented, migration to another platform is almost impossible.
Of course, the reason for working with a framework is to save time in the long run. HA frameworks and operating systems typically provide this by insulating the developer from the underlying hardware. This provides a level of portability for developers as long as the HA framework supports the desired hardware and software platform.
Saving time in both the development and approval process is part of the answer for companies that deliver frameworks like Green Hills Software, Lynux-Works, and Wind River. One area where approvals is important is the military. Approvals such as DO-178B take lots of time and effort to achieve. Developers try to minimize this as much as possible by documenting and checking their own portion of the application.
Security is another growing arena for new frameworks. Systems like .NET and Java include authentication and encryption support, yet they lack the larger management and underlying support for new hardware technologies and key management. Because this area is still evolving, these larger frameworks will play catchup with smaller security-oriented frameworks.
Likewise, embedded applications often will use products like Certicom's Security Builder Middleware. It can handle security devices as well as provide support for a wide range of authentication, encryption, and digital rights management on numerous hardware platforms.
GRAPHICAL FRAMEWORKS: Frameworks don't have to provide Internet support, high availability, or communication support to be useful. They may just deliver a pretty picture. In fact, some of the earliest frameworks were graphical frameworks.The Microsoft Foundation Classes (MFC) were delivered mostly to facilitate graphical-application creation for Microsoft Windows. MFC supports a broader array of functions in addition to handling the user interface, but the bulk of it performs window work.
Java has a number of competing graphical interfaces. Two stand out: Abstract Window Toolkit (AWT) and Standard Widget Toolkit (SWT). Like MFC, the GIMP Toolkit, and other graphical frameworks, the job is the same but the application programming interfaces (APIs) and architectures differ.
Eclipse, an open-source integrated development environment (IDE), is built using SWT. That's not surprising, since Eclipse is written in Java. Most IDEs are used to build applications or host application building tools. Of course, IDEs have some common attributes with most user applications.
Strip out the IDE-specific features, and you get the Rich Client Platform (RCP). There's even an embedded version of RCP (see "Eclipse: An Application Framework?" p. 47). Delve deeper into the RCP (the base of Eclipse) and you'll find the OSGi Services Platform. This framework pushes a software component model designed for reusability. It supports dynamic software updates, remote maintenance and diagnostics, security, and horizontal deployment features. Built on Java, it provides a portable platform that can be used by itself.
FRAMEWORKS ON TOP OF FRAMEWORKS: Building a framework on a framework is quite common even among third parties, assuming the specifications are open and stable. With Echelon's Lonworks Bundle Deployment Kit, developers can add connectivity via the OSGi Services Gateway and develop OSGi Service Platform device bundles. The latter can be delivered to an OSGi Service Gateway node for execution. Espial's DeviceTop provides similar support for its frameworks, such as IPTV.The appearance of more frameworks also can be pinpointed to the increased formalization of middleware support. For example, QNX has a power-management framework for its real-time operating system.
Many areas that aren't even mentioned above are available, from point-of-sale (POS) services to robotics to Voice over IP frameworks such as Asterisk (see "Open-Source Platform Dials Into VoIP," p. 34). Like most of the frameworks discussed, these others often have rigid requirements that limit their use to a small set of environments.
The bottom line is to make sure your applications can live within these constraints, because mixing frameworks may not be possible. Just try combining frameworks for high Availability, safety-oriented support, security, and robotics with a graphical-user-interface framework to see how many combinations are available. Right now, it may not be possible.
IN THE LONG TERM: The need for frameworks is undisputed, since they provide significant front-end savings and can be very economical in the long run. Yet keep in mind that signing on to use a framework doesn't just commit the current application design.It's a long-term relationship where upgrades, bug fixes, licensing, and so on must be considered. Access to source code can be an issue, especially for debugging. A larger factor may be understanding the details of the framework. Frameworks seem to have lots of feature creep, too. Once started, they continue to grow.
Framework designers may want to take a tip from the Mozilla crew with its Firefox Web browser, or from Eclipse. Both have a different plug-in environment comprising all components, including the base components for the target environment. Modularity is critical in embedded designs. Building a system up in a modular fashion can improve reliability and reduce memory requirements.
NEED MORE INFORMATION?Apache Software Foundation
www.apache.org
Certicom
www.certicom.com
Eclipse Foundation
www.eclipse.org
Echelon
www.echelon.com
Espial
www.espial.com
Green Hills Software
www.ghs.com
GIMP Toolkit
www.gtk.org
LynuxWorks
www.lynuxworks.com
Mozilla
www.mozilla.org
MySQL
dev.mysql.com
OSGi Alliance
www.osgi.org
QNX
www.qnx.com
Microsoft
www.microsoft.com
Monta Vista
www.mvista.com
MySQL
www.mysql.com
Sun
www.sun.com
Wind River
www.windriver.com