topical media & game development
[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

talk show tell print

object-oriented programming

[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

Software architectures revisited

The Web is, at the time of writing, still in flux. Yet it is becoming more and more the standard infrastructure on which applications are built. A recurring question is, `how do we build Web applications?'. There is no definite answer to this question. There is no body of solutions that may serve to indicate proven practice. But there is, definitely, a convergence towards objectifying, or object-orienting as it is called in  [OOWeb], the Web and its applications. Anyway, the following quote, taken from  [Practice], p. 10, says it all.

It is a brave architect who, in today's environment, does not develop, or at least consider, an object-oriented design.

Clearly, the architecture of the technological infrastructure of the Web, as well as the architecture of Web applications, may benefit from an object-oriented approach. Nevertheless, knowing this, we still do not know how to build actual Web applications.

Architectural software styles

class of architectures


slide: Architectural software styles
 From the perspective of software architectures, we may ask ourselves what architectural style, or for that matter which mix of architectural styles, we may deploy for building such applications. As a reminder, an architectural style, which characterizes a class of software architectures, consists of a description of the types of components used (processes, events, repositories), the (runtime) relations between these components (for example the network topology), possible semantic constraints (such as the immutability of particular components) and properties concerning communication and cooperation (such as the connectors or protocols used).

Themes and variations

technological constraints


  • OO -- simple call and return
  • CORBA -- independent components
  • WWW -- data centered
  • events -- independent components
  • logic -- virtual machine architecture
slide: Themes and variations
 A rather simple-minded categorization of architectural styles, reflecting obvious technological constraints, is given in slide arch-themes. Each of the styles is characterized by a single phrase capturing a central feature of the style. For example, an OO approach may be characterized by the fact that it embodies a simple call and return mechanism, which, by the way, gets its power from the fact that it concerns methods or, in C++ jargon, virtual functions. Events have proven to be an excellent means to obtain a high degree of independence between components. And logic, as has been argumented in section Logic, may be used to promote a clear separation between knowledge-level and system-level aspects of a system, by embedding a (virtual) logic machine.

The categorization is, however, simple-minded because, as we may observe in retrospect, most of the applications discussed contain elements of at least a couple of the styles mentioned. So, instead of discussing one style, we need to consider a mix of styles, and determine what mix of styles may be effectively used to create the applications we have in mind.

The architecture of the Web

To return to the Web, why is the notion of software architecture important? As indicated in slide web-architecture, for one, the Web is still growing at a rapid rate, and it is becoming increasingly important economically. So, we are faced with the problem of managing this growth, and, much sooner than we could have expected, with the problem of maintaining the applications that populate the Web.

Architectural issues
  • managing growth, maintaining installed base
  • enhanced functionality -- synchronized multimedia
  • improved technological infrastructure -- HTTP-NG
slide: Architectural issues

Secondly, the Web is continuously enhanced with new functionality, including, for example, synchronized multimedia as proposed in the SMIL standard, see  [SMIL]. Consequently, with respect to the technological infrastructure, we need to be able to accommodate new requirements, such as quality of service, needed for the timely delivery of multimedia material.

And thirdly, many attempts are being undertaken to improve the quality of the infrastructure itself, as exemplified by the HTTP-NG effort, which aims at higher speeds and a state-full communication protocol, see  [HTTP-NG].

As clearly stated by the Web's principal architect, Tim Berners-Lee, graceful extensibility has always been one of the primary goals in developing the architecture for the Web. In this respect, the Web differs significantly from other distributed technologies, such as CORBA, which does not allow for non-compliant extensions. In contrast, the Web does to a great degree allow for non-compliant extensions simply by ignoring them, until they become a standard. The challenge, then, from an architectural point of view, is to come up with better standards and better technologies without sacrificing the extensibility allowed by non-strict technologies such as HTML and HTTP.

Plugin architectures

To conclude this chapter, I would like to discuss briefly an extension mechanism that has proved to be invaluable for developing Web applications, the plugin architecture. Plugin architectures are becoming more and more popular, for `ordinary' tools such as Adobe Photoshop and Macromedia Director. In a Web context, the most notable examples are Netscape Navigator and Microsoft Internet Explorer, which both provide a facility to extend the browser with new functionality that is available in a dynamically loadable library.

Client NPP/CallbacksBrowser NPN/Calls
Instantiation and DestructionVersion Info
Stream NotificationStream Creation and Destruction
Reading and Writing StreamsStreamAsFile
LiveConnect

Plugin architectures are realized by using callbacks, in the same way as in object-oriented frameworks. Above, an overview is given of the callback functions required by the Netscape plugin architecture. These functions must be implemented by the (plugin) client, so that the browser can recognize and activate the plugin. Such callbacks encompass instantiation and destruction functions, notification when a stream is ready, functions for reading and writing streams, and the Live Connect functions, which enable the (plugin) client to communicate with Javascript functions and Java applets that are currently active. The browser, in return, provides convenience functions to obtain version information, to create or destroy streams or to store the contents of a stream in a temporary file.

It should be noted that the actual API for the creation of (Netscape) plugins is not object-oriented, although a partial class library is available to create plugins in an object-oriented manner.

Nevertheless, ignoring details, plugin architectures indicate what may become the dominant paradigm of the future, framework-like environments that are extensible by components following a clearly defined pattern or protocol; that is to say, components created according to the principles of object-oriented software development.

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

(C) Æliens 04/09/2009

You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.