AT&T BELL LABORATORIES
Date: June 9, 1995
From: O.B. Clarisse
B.A. Westergren
C.J. Nealon
R.E. Pitt
E.R. Beyler
Software Assembly Workbench (SAW)
The Software Assembly Workbench (SAW) is a software system providing a visual construction interface and a small portable service execution platform for creating and delivering networked services. It has been used to prototype multimedia services such as interactive video on demand, multimedia conference calls, and database information access over a variety of infrastructures including the AT&T VCTV cable TV system and the AT&T Globeview 2000 ATM switch. SAW services have been demonstrated by AT&T at tradeshows such as SuperComm'94, NCTA'94, and InterOp'94.
The service construction paradigm provided by SAW is patterned after hardware design of integrated circuits. The diagrammatic composition in SAW, like in CAD circuit layout systems, uses "wiring" from output to input pins to define the paths of control flow and potential information exchange between software components. It is a multi-layer composition system where software components (referred to as building-blocks) are wired together at each layer to form the next higher layer of components or services.
What is unique about the SAW approach compared to other visual software composition tools (e.g. PrographÒ, AppgenÒ, Cypress PhoneproÒ, SmartphoneÒ) is that SAW uses an asynchronous model where all software components can execute concurrently with other components and services within the system. The wiring is not restricted to sequential control flow dependencies. This allows for rapid prototyping of applications that can control multiple distributed resources in parallel, a common requirement for multimedia services.
The SAW platform has an abstract communication operating system (COS) for creating and executing service applications. This COS supports a component-oriented architecture where services are created from communicating software components. The COS architecture offers control functions that support multiple service instances, provisioning, execution, and provides firewalls between users and services.
A SAW service can be viewed as a directed graph of reusable software components that are strictly layered and mapped to a protocol stack. Each component is an autonomous finite-state machine that responds to input events (stimuli), performs some internal processing, and then issues output events in response. The implementation of these machines was originally inspired by the work on Actors [AGH86]. Each software component behaves like an independent agent, communicating with its neighbors through input and output events.
Each component is itself built from a set of more specialized communicating components. At the top, the highest level components are service applications, and at the bottom of the stack the lowest level components are capabilities that communicate directly to external resources. Events from external resources are sent and received with local drivers for protocols such as UDP, TCP/IP, or DTMF.
Each component is fully described by its parts (subcomponents) and a list of its transition formula (event rules). Interestingly, this description provides a one-to-one mapping between each component's internal communication logic and its graphical presentation in the wiring diagram. Therefore, at a given layer the wiring between components exactly defines the communication protocol between a set of reusable components. The series of cascading layers corresponds to the protocol stack for the overall communication system defined in the application.
By design, a SAW service description captures the service logic as a uniquely dynamic architecture where each service is a connected graph of reusable components. Moreover, the service description is largely independent of the physical location of any of the components in a distributed network architecture, so it is possible to experiment with various network configurations without affecting the service description or execution.
SAW can be viewed as a bridge between authoring systems and network resources. This bridge is designed to provide two main functions: interactive visual service creation and control of distributed network resources.
SAW provides a practical environment for prototyping multimedia services using a variety of multimedia resources over various types of networks. At one end of the multimedia spectrum, authoring systems (e.g. MacroMind DirectorÒ, Gain MomentumÒ, IconAuthorÒ, Autodesk AnimatorÒ, Adobe PremierÒ) provide advanced graphics composition tools to create a wide range of multimedia content (still images, interactive presentations, interactive animations, computer generated videos). At another end of the spectrum is the growing broadband network consisting of resource servers (e.g. video servers, database information servers, video bridges), networks (e.g. ATM, cable TV, fiber, coax), and endpoints (e.g. set top boxes, PC's, workstations). SAW helps to cover the entire multimedia spectrum by integrating multimedia content and control of network resources into one system that can be used to prototype new services and discover new combinations of resources that provide unique advantages to the service and network providers.
For example SAW can be used to build an interactive multimedia information retrieval service that enables playback of video from a network video server, using content from MacroMind DirectorÒ animations and graphics, and delivered over an ATM connection to a PC or set top box. SAW provides a abstract communications interface to orchestrate the use of these various multimedia resources. SAW can also help manage the complexity of provisioning such services by accessing standard database systems that are Open Database Connectivity (ODBC) compliant. SAW supports ODBC enabling transparent SQL communication with a wide variety of standard databases. In addition, SAW provides a small service management and execution environment for running the services: each service is automatically maintained and executed on demand for each user.
The SAW architecture comprises a visual construction system that is seamlessly integrated with a service execution platform to provide interactive simulation and debugging functions. Services that have been constructed and tested using the SAW system can then be loaded into one or more SAW execution platforms (called SAW service servers) to provide real-time service delivery and increased execution capacity.
The SAW service servers can be placed within the network or at the end-points. When placed in the network, the SAW systems can directly control network resources (such as databases, switches, video servers, etc.) and provides network services. When placed at an end-point the SAW system controls only those devices at the customers premises.
The SAW service server can also be used in contained service offerings for campus-like environments. In this configuration the SAW service server provides local services and controls the network resources within the campus environment (e.g. businesses, schools, resorts, etc.).
The Software Assembly Workbench (SAW) provides a visual approach for assembling software by combining reusable components, much in the way electronic hardware is designed. This approach assumes an interconnected collection of Network Elements providing networking functions and resources for the supported application domains.
New software applications are constructed by assembling components according to a dual partition. A horizontal partition classifies components by application domain (e.g. voice, video, database, fax) and a vertical partition classifies components according to their conceptual proximity to available network elements (hardware). The vertical partition uses three principle software levels, the application (upper) level, the component (intermediate) level and the communication (lower) level as shown in Figure 1. Intermediate levels of components such as primitive (i.e. smallest component encapsulating a functionality exported by a resource element), capability (i.e. minimal reusable combination of primitive components) are sometimes used to refine the vertical classification. To facilitate reuse, components are grouped into several libraries (represented by palettes of graphical objects) classified by application domain and by level.
Figure 1. Layered composition of networked applications
As viewed in Figure 1, components (drawn as disks) are constructed using ports (drawn as boxes) from the communication layer and other low level components. SAW supports several intermediate levels where components are constructed by composition of other components. In the upper layer, applications are constructed out of components. Service gateways and multiple application offerings are further composed out of available applications (possibly from different domains) and components.
Intermediate levels are introduced on demand to manage the complexity of an application by successive composition. A new level can be constructed when a set of abstractions reusable in multiple applications has been identified by the application domain analysis. This approach supports progressive refinement of an application (rapid prototyping) and accelerates the restructuring of existing applications for effective reuse. The amount of software reuse increases in the higher layers of SAW as shown in Figure 1.
Figure 1 also illustrates how components at a given level in the SAW classification collaborate using peer-to-peer communications, and how components from different levels collaborate via client-server communications. In the peer-to-peer communication model, all components are equal partners and can issue requests directly to other components. In addition, components directly composed to form a higher level component are registered in a name-space (local to their parent component) allowing direct peer-to-peer communication by name (simpler protocol definition, lower overhead in communications). In the client-server communication model, one component (upper layer) is designated as client and issues requests to connected servers (lower layer) providing the required service (e.g. computation, handling, storage). Client-server requests are usually transmitted to external resources via ports (using address translation and network routing).
Figure 2. From simulation to execution
Communication between SAW elements at all levels is message based and event driven. A link between two elements represents a simple protocol used to transfer information between these elements: a message comprising the required output event and associated data enters the link at one end and a message comprising the required input event and corresponding data is generated at the other end of the link. When a communication is relayed via ports, the output message is encoded into a packet, sent via a socket, transmitted over a network, and decoded into an input message on the other end. This communication system abstracts all information exchanges (internal or external) between composable software elements so that the software specification remains largely independent of the actual communication mechanisms involved and of the physical distribution of components in the network.
The software constructed using the three layers of the Software Assembly Workbench is first designed in a controlled simulation environment using local emulators as substitutes for external resource elements. The software is then verified through simulation in a controlled laboratory environment using experimental network elements (resource servers) and service end-points connected through a sample connection network. Finally the service is released for execution in one or more SAW service servers deployed in the target network. Figure 2 illustrates the transition process between simulation and execution. In simulation the software component architecture remains dynamic allowing the application designer to experiment with various mappings of components into the network elements. In execution, groups of components are associated with specific execution elements. The component architecture is fixed when a specific component mapping is chosen.
During the process of controlled simulation in SAW, the dynamic architecture is fully preserved allowing rapid reconfiguration of the software system for performance tuning and load balancing. The release mechanism removes some of this flexibility by mapping software components into physical execution platforms.
The simulation environment of SAW shortens the feedback loop of the software development cycle by allowing the rapid assembly of realistic applications. For example local emulators (Figure 4) are used to show immediately and realistically what the final application will look like once deployed on the network. The execution system of SAW is designed to execute the application code directly produced by SAW and used earlier in simulation. In other words, a single set of source code is used to represent an application both in simulation form and when distributed on SAW execution systems. This simplifies the application code administration, delivery and deployment process. This is achieved by providing a common portable execution engine for all platforms (including the SAW graphical simulation platform).
The SAW architecture comprises a graphical service creation system seamlessly integrated with a service execution platform to provide interactive simulation and debugging functions. Services that have been constructed and tested using the SAW system and methodology summarized above can be loaded into one or more execution platforms, called Application Control and Execution platforms (ACE). The ACE platforms are service servers that can be distributed on a network to provided increased execution capacity and optional redundancy of service offerings for reliability. To test the effectiveness of this approach, the SAW execution engine has been ported to many operating systems including UNIXÒ (Solarisä), HPUXä, Windowsä, Windows 95ä beta and Windows NTä. In addition, applications have been created using SAW based on distributed components cooperating across multiple ACE platforms (i.e. different machines with different operating systems).
A typical use of ACE service servers in a multimedia service architecture is shown in Figure 3.
Figure 3. ACE service servers in a networked multimedia application
DB 1 and 2 are provisioning databases for customer associated service data. SAW supports ODBC enabling transparent SQL communication with a wide variety of database management systems. ACE 1, 2 and 3 represent instances of ACE execution platforms supplying a set of users with a variety of multimedia services. The distribution of users on ACE instances can be the result of load balancing or customer classification schemes (e.g. silver, gold, platinum). The EP objects represent a variety of user end-points (e.g. PC, TV and set top box) accessing services provided by ACE or coordinated by ACE. In the background the network elements comprise multimedia resource servers (e.g. video players, ATM switches, encoders, decoders, contents databases).
In this service architecture, the ACE platforms can directly control part of the multimedia resources (e.g. via packet protocol) while other resources can be controlled by middleware platform implementing the allocation and control of resources and specific service functions.
In the following example, a SAW system is dedicated to the interactive video on demand (IVOD) subdomain of multimedia services. Figure 4 shows an example of software emulators used during the design of an IVOD service. The emulators replace a television, a set-top-box and a remote control box by software interfaces and corresponding software components that emulate the actual hardware to be distributed on a delivery network.
Figure 4. IVOD software emulators
The target is a communication network of computers and other equipment needed to support an IVOD application (see figure 5). The lab configuration includes an ATM switch to support virtual circuits between end points, and an Ethernet backbone for control signaling. In a field target, the ATM infrastructure would carry the signaling, eliminating the need for the Ethernet network.
Figure 5. Target Network Architecture
There are two parts in creating an application, the graphical assembly and the execution (simulation) in the SAW environment.
The domain operators for IVOD are represented using a palette of icons (Attachment 1). Icons that are selected and placed into the design area are instantiated into fully functional software components. Graphical components are then graphically connected (wired together as on Attachment 1) to create service software.
A graphical component accepts input events and generates output events upon successful completion or failure of its tasks. A component may be created using other components from the palette or from a lower level palette, or it may internally use a control flow "diagram" (and code) to perform its tasks. In this computational model there is no sequencing of component execution. Each component processes events independently from the other components involved in the service. Parallelism is inherent to the event-based interactions between components [AGH86], [CHA94], [LEE94]. This approach is well suited for the video and multimedia domains where services frequently require the coordinated access of multiple resources from possibly disjoint network elements. It also is essential to our strategy for scaling applications to meet increased demand.
A diagram constructed in this paradigm comprises a set of components and a set of connections representing event associations (between component output events and input events). An example of such diagram, presented in Attachment 1, resembles a circuit diagram. However, each connection between components does not represent an absolute point to point "wire" connection, but instead a potential path for transmitting packets of information (event and data) between two or more components. In the example of Attachment 2, the Play (video) component is composed of other components including: video-resource, signal-router, post, video-end, connection, start-video, and display. The signal-router is a port, a component of a special class (displayed in a different color) used to communicate with the signal router system (an external routing software in service execution or a local software emulator in service simulation).
The software assembly paradigm is based on logic circuit design as shown in Attachments 1 and 2. It is a multilayer composition system where the software components are wired together at each layer to form the next layer of components. The diagrammatic composition in SAW, like in a CAD circuit layout, uses wiring between output and input pins to define the paths of potential information exchange between software components according to a communication protocol. The wiring is not restricted to control flow dependencies. This allows for rapid prototyping of applications that control multiple resources (distributed) in parallel, which is a fundamental requirement for multimedia applications. Each component is an independent communicating process that runs concurrently with all other components.
SAW supports an architectural layering and set of API's for software visualization, construction and execution in addition to a component layering and a set of API's for component presentation and communication.
The architecture supports a Visual Construction Layer (VCL) and a Component Execution Layer (CEL). The VCL and the CEL are disjoint pieces of software that communicate through an application programming interface (API). This allows the support of user defined paradigms for graphical construction through spreadsheets, 4GL's, tables or any method of choice. The SAW delivered paradigm is a drag-and-drop of components from a palette (Figure 6), connection of components through circuit wiring (Figures 7 and 9) and popup editors for component customization (Figure 10).
Figure 6. Dragging a Component from the Palette
Figure 7. Visual Construction Through an API
The SAW environment allows the construction of components in multiple layers. The lowest layer consists of a set of primitive functions and ports. These are constructed through the application independent specification language defined for SAW. A primitive layer component is manually coded and remains constant. It is essentially a glue point between the network hardware and component construction. The next layers can then use this primitive component to create specializations. A component is typically a composition of multiple components (Figure 7). The SAW environment provides for on demand aggregation of components to simplify the visualization of the application and provide for the reuse of frequently used component combinations. A SAW component is self-describing. This means that when solicited, the component must present its interface to the caller (Figure 8). The component declares its interface through connectors. On the left are the input connectors indicating the events and arguments required to activate its actions. On the right are the output connectors indicating the events and arguments elicited from the component (Figure 8).
.
Figure 8. Component Interface
There are two ways to construct a component in the SAW environment. The first is the manual encoding of a primitive or core layer component. This utilizes low level functionality specific to an individual network element. Once the primitive layer component is constructed it forms the base for component specialization for various application domains. The primitive components form the base for the second method of component construction. Creating aggregate components to construct application layer software (Figure 9). The visual construction techniques are used to drag-and-drop components from the palette (Figure 6), connect the components, edit the connections, define the provisioning interface, provision the data, and select a graphical appearance. The final steps are to save the component to a particular library, identifying the component as a reusable entity.
An integral part of the component construction process is the communication to external devices. This is supported through a SAW abstraction called Ports. A Port is also represented as a component that is located in a separate palette. The Port component can then be dragged from the palette into the SAW design space for connection to the other components. The Port can be provisioned with network element specific information to support processor specific addressing.
It is expected that many basic components can be reused across various application domains. These will form the library of core components which can be reused across domains. It is assumed that the core components will have the largest reuse. It is possible that the real power of reuse will come from the specialization made possible with aggregated components.
Figure 9. Component Construction
Application creation is the top layer in SAW. Multiple palettes of components are available for constructing the desired application functionality. The creator can dynamically switch between palettes to select the desired components. The process for developing an application proceeds with the dragging of a component from the palette into the SAW design space. When the component is dropped, its interface presents itself in the form of input and output connectors (Figure 8). When more than one component is present the user can connect them by clicking on the output of one connector and then the input of another (Figure 9). Automatic parameter matching is performed with the option to augment the data, through the connection editor. Each component can be customized further through its individualized provisioning interface (Figure 10). This is where the data for each customer is entered. The result is a graphical representation of the application. This is then automatically transformed into the applications logic language by SAW. No additional software construction is required to create a custom solution from the components assembled in SAW.
The provisioning system of the SAW environment allows customizing components on an individual customer basis. When a component is selected from the palette, the logic is reused and a private data space is set up and populated with customer specific information. Each customer can have unique information provisioned for a component instance allowing the component to act differently based on the data loaded into its data space. A component provisioning language (CPL) has been developed (Figure 10) to allow the component developer to declare the data types and ranges. SAW dynamically generates the user interface for entry of these data variables.
Figure 10. Provisioning a component
Several domains from the software industry advanced the effectiveness of software reuse, and are important to accelerate the construction of new software applications from reusable components, they include:
Domain Analysis.
Visual composition paradigms.
Component assembly methods.
Object brokering, object distribution and resource recycling.
Application Programming Interfaces and open interfaces.
Extensible communications protocols (e.g. based on self-describing extensible message sets).
Platform independence.
The two previous sections (2.1 and 2.2) presented general aspects of the SAW architecture that contribute to software reuse in these domains. This section (2.3) further examines SAW's contributions in domains 4, 5, 6, and 7 and compares them with related approaches from the software industry. The following section (2.4) compares and contrasts SAW in domains 2 and 3 with related approaches. Finally, section 2.5 highlights specific examples using SAW in different application domains.
There are a number of participants in the arena of reusable components ranging from the large cross industry consortia and the established system vendors to small entrepreneurial software houses. The most dominant of these are Microsoft's Component Object Model (COM), IBM's System Object Model (SOM) and the Object Management Groups (OMG) specification of the Common Object Request Broker Architecture (CORBA). The OMG is a consortia of more than 300 hardware, software and end-user companies. The SAW architecture provides for a construct for component reuse using an underlying Component Operating System.
These architectures all must address the concerns of naming, address space conversion, transport protocols and interface description. These are complex issues when dealing with distributed architectures and the component technologies are attempting to simplify this by way of abstraction.
The Object Management Group was founded in 1989 to adopt a standard for inter-operation of software, specifically, object-oriented software across operating systems and platforms in a heterogeneous networked environment. CORBA is a specification of an architecture and interface which allows applications to make requests of objects in a transparent, independent manner, regardless of language, operating system, or location. It does not include anything about a particular implementation and apparently, CORBA compliance does not imply compatibility.
Microsoft's COM is more than a specification; it is a delivered product that specifies a binary standard for object interaction. Objects that adhere to this standard expose to client processes various sets of function pointers, or interfaces. The COM manages the instantiation of these objects including allowing in place activation, linking, embedding, drag-and-drop, uniform data transfer, automation and compound files. The user is also able to specify custom interfaces. The first implementation of the COM is through the Object Linking and Embedding (OLE) protocol set. This implements a mechanism for compound document sharing.
IBM's System Object Model utilizes the Interface Definition Language to define component interfaces and attributes. Once specified, the SOM compiler generates the stub and skeleton bindings for the language of choice. The SOM compiler uses back-end code generators which perform the actual mapping of IDL syntax into the implementation language and generate the implementation skeletons. On the client side the code generators create include files that specify the method signatures clients use to invoke methods on components. There are two strategies that can be used to invoke a method, offset resolution and name lookup resolution. The former is a compile time binding while the latter is a runtime binding. The tradeoffs between these two approaches are the speed of execution. This is due to the name lookup requiring a search of a number of data structures associated with the class.
The SAW platform has an abstract component operating system. The COS offers control functions for multiple component instantiation, provisioning, execution and provides fire-walls between users and applications. A SAW service can be viewed as a directed graph of software components that are strictly layered and mapped to a protocol stack. Each component is an autonomous finite-state machine that responds to input events (stimuli) by doing some internal processing and issues output events in response. The implementation of these machines was originally inspired by the work on Actors [AGH86]. A component behaves like an independent agent communicating with its neighbors. A component is fully described by its parts (subcomponents) and a list of its transition formulas (event rules). Interestingly this description provides a one-to-one mapping between the components internal communication logic and its graphical presentation as a wiring diagram. Therefore, at a given layer the wiring diagram between components exactly defines communication protocol between as set of reusable components. The series of cascading layers corresponds to the protocol stack for the overall communication system defined in the application. Each component is itself built from a set of more specialized communicating components. At the top, the highest level components are service gateways, or specific services, and at the bottom of the stack, the lowest level components (capabilities) communicate directly with local drivers or to external resources (distributed) via protocols (e.g. UDP, TCP/IP).
Attributes of COS contributing to effective component reuse:
Uniform communication scheme that is extensible without rewriting code in multiple layers.
Components addressable by name.
Dynamic software updates allowing software changes to be integrated with low overhead while the system is still alive.
Optional run time type checking for enhanced safety.
Condition handling with recovery, allowing a potentially unique recovery strategy for each fault. Problems are caught and dealt with in a layered approach.
Object persistency provided by an OODBMS, providing recovery after a shutdown.
Recent change of persistent components.
The Software Assembly Workbench differs from commercially-available, visually-oriented application creation tools in several important ways. The SAW is designed for event-driven applications on distributed networks, unlike authoring tools which are designed for stand-alone applications on personal computers, workstations or kiosks.
The SAW is designed to simplify application creation by using building block selection to restrict the domain, unlike more general-purpose computing tools. Finally, the SAW is designed to allow drag-and-drop creation of entire applications, unlike telecommunication tools that require coding of state machines in a proprietary language
There are numerous, commercially-available authoring tools for creating presentations, courseware and games. They all differ from the SAW primarily because they are designed to create stand-alone applications; all the resources needed (with few exceptions) are part of the platform on which the completed application runs. They also tend to be very content-oriented and often include drawing, animation and video tools to create content. Three examples of this class of tools, representing most common creation paradigms are IconauthorÒ, Sybase Gain MomentumÒ and Macromedia DirectorÒ.
In Gain Momentum, the focus of the GUI is the application's user interface; one creates the different screens of an application by dragging-and-dropping objects such as buttons, images, and static text. Simple object behaviors, such as navigating to another screen, can be set through the GUI. More complicated behaviors are coded using a proprietary language.
In Director, the focus is again on the application's user interface, but one creates the different screens by assembling "cast members" (text, audio, image and video objects) on a "stage" (screen) and defining their behavior on a time line to create a "movie". One sets object behaviors by writing "scripts" in a proprietary language.
In IconAuthor, the focus of the GUI is the application's behavior; one creates a flowchart of the logic by dragging-and-dropping behavior elements such as decision branching and screen displays. The application's screens are usually created with other tools and imported as images.
There are several commercially-available tools for creating networked telecommunications applications, especially for Advanced Intelligent Networks; AT&T's A-I-Net and Bellcore's SPACEÒ are two examples. In many ways, the SAW is intended to be an extension and refinement of these earlier efforts. Like the SAW, these tools can be used to create event-driven applications on distributed networks. However, there are some significant differences. Unlike the SAW, most of the effort in creating an application goes into writing the required finite state machines in either a proprietary application-oriented language (A-I-Net) or a general-purpose language (SPACEÒ). Only a limited set of functionality, such as decision graphs, can be created using a drag-and-drop user interface. They also lack the layering and reusable, predefined objects that simplify application creation
A comparative study was performed between the Component Assembly Technique (CAT) currently used with SAW and the Real-time Object-Oriented Modeling method ROOMä [SEL92-93]. Of the available object-oriented methods, ROOMä is the closest to CAT and covers the most complete object-oriented modeling method known. A comparative study of Shlaer/Mellor Object Oriented Analysis (OOA) [SHL92] and ROOMä was also performed by our colleagues C. Duon, O.I. Henjum, D.A. Vadner and L.W. Zurawski [DUO94]. The results from these studies are in agreement with our initial experience designing components for reuse in the multimedia domain and are summarized in Table 1. Table 1 presents for three methods (CAT, OOA, ROOMä) the relative degree (Low, Medium, High) of support for five selected enablers of software assembly:
Overview: ability to represent the architectural overview of a complex software system.
Reuse: ability to support direct reuse of existing components in building new software.
Encapsulation: ability to hide the implementation of a software component behind its interface.
Inheritance: ability to access and specialize the functionality of a component without referring to its internal implementation.
Composition: ability to combine the functionality of existing components without affecting their respective implementations.
|
Attribute\Method |
Overview |
Reuse |
Encapsulation |
Inheritance |
Composition |
|
CAT |
Medium |
High |
High |
Medium |
High |
|
OOA |
High |
Low |
Low |
Low |
Medium |
|
ROOM |
Low |
Medium |
High |
High |
High |
Table 1. Comparison of three software design methods
In particular in Table 1:
CAT provides better support for component reuse than OOA and ROOMä. This is derived from SAW's ability to organize reusable components in multiple palettes for various domains and levels, and the SAW component model support for reuse of components (and protocol APIs) independently of the communication medium.
OOA provides a better description of the global system overview than CAT and ROOMä. However CAT provides a dynamic representation of the overall system design through SAW's support for networked application simulation, animation and emulation. The combined ability of CAT and SAW to support complex system overviews may well be rated as High.
ROOMä provides better support for inheritance (for both object and protocol specifications) than CAT and OOA.
CAT and ROOMä both provide hierarchical decomposition more expressively than OOA, the Booch Method, and Rumbaugh's OMT which all lack effective abstraction mechanisms to ease the representation of complex communication systems.
The CAT and ROOMä are based on the use of an underlying Object-Oriented Language (OOL). While OOL's don't support all aspects of reuse [NIE92] they encourage two important aspects of component reuse: the decomposition of complex software into manageable cooperating software components and the assembly of new components by aggregation and specialization of components from libraries. In addition the approaches taken in CAT and ROOMä favor concurrent engineering: components are fully encapsulated and their interfaces clearly specified by protocol APIs encouraging parallel development. For example, CAT was used to concurrently re-engineer an application in six weeks (with four developers) by adapting a solution from a digital ATM switching network to a prototype cable-TV network. CAT and SAW have also benefited from joint effort on behavior modeling [KOW92] and recent research work on automatic scenario validation techniques [HAL93].
Several software engineering tools such as Software Through PicturesÒ (IDE), LOV/GEODEÒ (VERILOGÒ), ObjecTimeÒ, or STATEMATEÒ can be purchased from CASE tool vendors. These tools are associated with system design methods such as OOA, OMT and ROOMä and exhibit the corresponding advantages and limitations summarized above. In addition these CASE tools make every effort to provide broad and general software engineering support for all domains, while software construction in SAW is dedicated to specific application domains. By creating application domains in SAW, one can insure that a simpler construction technique is possible and increase the chance of effective reuse by non expert users.
The VERILOGÒ suite of tools is very well suited for detailed telecommunication applications (it supports SDL and MSC recommendations from ITU-T and relies on several telecommunication standards), however this approach requires expert knowledge in telecommunication standards and limits the creation of software assemblies to expert users. STATEMATEÒ is based on Statecharts [HAR87] providing important abstraction advantages over state diagram modeling approaches. ObjecTimeÒ and ROOMä provide a software construction approach superior to STATEMATEÒ in the telecommunication domain. However ObjecTimeÒ requires explicit knowledge of an object-oriented language that is better abstracted away in SAW by the visual construction paradigm.
Three different application domains have been implemented using our prototype software assembly workbench: 1-800 Services (such as 800 call routing, call queuing, and voice mail), Interactive Video on Demand Services (home-based digital video play-back with VCR-like control), and Multimedia Desktop Video Conferencing Services (PC-based video calling and data sharing system).
Application domains were chosen that required a high degree of customization in order to meet service requirements. For example, in the 800 services domain each service requires customized calling features such as how to route calls (e.g. time-of-day, day-of-week, by caller-id) or customized audio menus and announcements. Similarly, video on demand services require frequent changes to keep the audience interested (e.g. available movies may change every week). These types of highly customized domains allowed us to explore our software assembly approach and the extent to which our component-oriented software supported reusability.
The first application domain implemented was for 1-800 services. This application domain allowed us to create customized 1-800 inbound call management services that could be used in a narrow-band voice network.
The reusable components of the 1-800 domain were created and integrated into the graphical software assembly workbench for creating customized 1-800 service applications. Sample 1-800 building blocks include:
|
ROUTING |
TIME-OF-DAY |
Route call based on time of day |
|
|
DAY-OF-WEEK |
Route call based on day of week |
|
|
CALLER-BASED |
Route call based on the caller's DN |
|
|
CALLER-SCREENED |
Deny call based on the caller's DN |
|
ANNOUNCEMENTS |
PLAY |
Play pre-recorded audio message |
|
|
MENU |
Route call based on caller selection from list of options (e.g. "Enter 1 for customer service", "2 to place an order", "3 for store hours", ...) |
|
TERMINATIONS |
INCOMING |
Incoming call |
|
|
ADD-PARTY |
Connect incoming call |
|
|
END-CALL |
Clear call |
|
|
BUSY |
Forward call if destination is busy |
|
|
NO-ANSWER |
Forward call if no answer at destination |
Table 2. 1-800 Building Blocks
The 1-800 service building blocks are used to construct customized 1-800 calling services. For example, a simple 1-800 service for calling the White House was created. The service included a greeting, routing based on day-of-week and time-of-day, and a menu allowing the caller to request either speaking to Hillary or Bill, or hearing an announcement on the current national debt. The caller would be routed to the menu only during normal business hours. During weekends and weekday non-business hours the caller would be routed to an announcement asking them to call back during regular business hours.
To create the White House service, the 1-800 service building blocks described above were used. The INCOMING TERMINATION building block is used to accept the incoming call and signifies the start of the service. The service starts off with the PLAY ANNOUNCEMENT building block playing a pre-recorded audio greeting to the caller (e.g. "Hi, Welcome to the White House Call Center"). Next the TIME-OF-DAY and DAY-OF-WEEK ROUTING building block is used to route the call based on the time and day.
If the call is placed outside of normal business hours the caller is routed to a PLAY ANNOUNCEMENT building block to play a pre-recorded audio message indicating that the caller should call back during normal business hours. The call is then terminated with an END-CALL TERMINATION building block.
If the call is placed during normal business hours, then a MENU ANNOUNCEMENT building block is used to prompt the caller for their selection. If the caller chooses to speak with Bill or Hillary, the ADD-PARTY TERMINATION building block is used to connect the incoming call. If the caller wants information on the current national debt, the PLAY ANNOUNCEMENT building block is used to play a pre-recorded audio message. The call is then terminated with an END-CALL TERMINATION.
The above service required six different building blocks, of which we reused the PLAY ANNOUNCEMENT building block three times and the END-CALL TERMINATION two times.
The target network architecture for the 1-800 services was an Advanced Intelligent Network for voice services (shown schematically in Figure 11). In this network, an incoming 1-800 call is routed to the 1-800 switch over a trunk, and control of the call begins in the Network Controller. The Intelligent Peripheral provides functions needed to support call control (e.g. voice announcements and digit reception). If appropriate, the call is completed to the appropriate 1-800 call agent. The Service Assembly Workbench generates executable code for the 1-800 Switch, the Intelligent Peripheral, and the Network Controller, as needed for each service.
Figure 11. Video On Demand Building Blocks
The next application domain implemented was for interactive video on demand services designed to be viewed over a TV (Attachment 3). This application domain allowed us to experiment with new interactive services that might be delivered over a broad-band ATM (Asynchronous Transfer Mode) or cable TV network.
The reusable components of the video on demand domain were created based on the capabilities of the target delivery system (i.e. ATM, fiber, coaxial cable, TV set top box, video server, etc.). Sample Video On Demand Building Blocks include:
|
SIGNALING |
START |
Incoming service request |
|
|
PLAY |
Sets up path to video server and plays video |
|
|
REMOTE-CONTROL |
Enables VCR-like control of videos |
|
|
TUNE |
Tunes STB to specific channel |
|
PRESENTATION |
DISPLAY |
Displays text or image to user |
|
|
MENU |
Displays text or image and collects user selection from list of options |
|
|
MOVIES |
Displays list of movies from video server and collects user selection |
|
BILLING |
DATABASE |
Allows insert, update, and delete of database |
|
|
FOLIO |
Obtains billing data from database and displays current account information to user |
Table 3. Video On Demand Building Blocks
The video on demand building blocks can be combined to construct customized interactive video services. Interactive services that were created included movies on demand, travel information, product information, home shopping, and on-line bill review. Services were created for both ATM-based and Cable TV-based delivery to the home.
For the digital ATM-based system a simple video information service was created that a consumer might use in the home. This service delivered video from a digital video server over ATM to the user's STB. The service included displaying a welcome screen, allowing the user to select from a menu of video categories: movies, travel, and specials, and then allows the user to select and play a specific video, including having access to VCR-like playback control (e.g. pause, rewind, fast-forward, play).
To create the video information service, the Video On Demand building blocks described above were used. The START SIGNALING building block is used to accept the incoming service request from the user (e.g. initiated by STB when user tunes to advanced service channel on TV) and signifies the start of the service. The service then starts off by displaying a welcome screen using the DISPLAY PRESENTATION building block. Next the MENU PRESENTATION building block prompts the user for a selection from a list of video categories.
If the caller selects movies, the MOVIES PRESENTATION building block is used to prompt the user with the list of available movies from the video server. After selecting a movie, the PLAY SIGNALING building block is used to set up the ATM connection to the video server and begins playing the movie. The CONTROL SIGNALING building block is then used to enable the use of VCR-like control of the video. When the video is over the service returns to the main category selection menu.
Similar building blocks are used to implement the "travel" and "special" categories of the video information service. In the case of "travel" the content is travel information instead of movies and for "special" the content would apply to whatever product was being marketed (new movies, merchandise, games, etc.). The above service required six different building blocks of which we reused the MENU PRESENTATION building block four times, the PLAY SIGNALING building block three times and the CONTROL SIGNALING building block three times.
There are two Video on Demand target network architectures: one for delivering video and other services over a broadband ATM network, and one for delivering them over coaxial cable (it is also possible to combine the two architectures, transporting ATM by modulation over a coaxial cable). The broadband ATM network is appropriate for large networks with video servers and customers widely separated. The cable network is appropriate for small campus-like networks.
The broadband ATM network architecture is shown in Figure 12. Services are controlled by the SAW with direct links to the video server and the ATM switch and as part of the ATM stream to the Set Top Box.
Figure 12. Broadband ATM Video on Demand Architecture
The coaxial cable architecture is shown in Figure 13. Services are controlled by the SAW with direct links to the video server and the RF modem and as part of the modulated signal to the Set Top Box.
Figure 13. Coaxial Cable Video on Demand Architecture
The other application domain implemented was for multimedia desktop video conferencing applications delivered over an ATM-based network (Attachment 4). This includes services such as placing video calls, sharing data files, and retrieving video messages from a video answering machine.
The reusable components of the video conferencing domain were created to support video calls, data file sharing, and pre-recorded video message retrieval. Sample video conferencing building blocks include:
|
Call Control |
IDLE |
Sets call to idle state (no call) |
|
|
ANSWER |
Incoming call |
|
|
END-CALL |
Answer incoming call |
|
|
ADD-MEDIA |
Clear Call |
|
Data Signaling |
SEND-HTML |
Send HTML data message |
|
|
HTML-RESPONSE |
Response to HTML data message |
|
|
AUTHORIZE |
Prompts user for login and password |
Table 4. Multimedia Desktop Video Conferencing Building Blocks
The video conferencing building blocks are used to construct customized video conferencing services. For example a message retrieval service for retrieving video messages from a networked based video answering machine was created. The service included a login/password prompt, a menu allowing the user to select and playback a message from the list of video messages received.
To create the this service, a combination of the video conferencing domain building blocks for the call and data signaling and the video on demand domain building blocks for the video playback and control of the video server were created. The service begins with the INCOMING CALL CONTROL building block which is used to accept an incoming call. The ANSWER CALL CONTROL building block is then used to answer the call by sending the appropriate signaling messages to the far end.
Once the call is established, the service starts by prompting the caller for their login and password using the AUTHORIZE DATA SIGNALING building block. Once the caller is authorized, the MENU DATA SIGNALING building block is used to display a list of video messages to the caller. Once the caller selects a video message, the PLAY and CONTROL SIGNALING building blocks from the Video On Demand domain are used to play back the video message and enable VCR-like control of the video. When the video is over, the service returns to the menu of video messages and may choose another message or end the call. When the caller hangs-up the END-CALL building block is used to clear the call.
The above service required 8 different building blocks of which the PLAY and CONTROL building blocks from the Video On Demand domain were reused.
The Multimedia Desktop Video Conferencing target network architecture, shown in Figure 14, differs from the broadband ATM Video on Demand architecture shown in Figure 12 in that the SAW-controlled Video Message Server is not a network element. Rather, it is an endpoint; when one wants to retrieve video messages, one calls the server, and the call is completed like any other broadband ATM call.
Figure 14. Multimedia Desktop Video Conferencing Target Network Architecture
The Software Assembly Workbench has proven to be a useful approach for the visual assembling of software utilizing reusable components. It has also demonstrated its ability as an execution platform for delivering network services. It has been used to prototype multimedia services such as interactive video on demand, multimedia conference calls, and database information access over a variety of infrastructures including the AT&T VCTV cable TV system and the AT&T Globeview 2000 ATM switch. SAW services have been demonstrated by AT&T at tradeshows such as SuperComm'94, NCTA'94, and InterOp'94.
The SAW platform contains a middleware layer called the communication operating system (COS) for creating and executing service applications. COS supports a component-oriented architecture where services are created from communicating software components. The COS architecture offers control functions that support multiple service instances, provisioning, execution, and provides firewalls between users and services. This allows SAW service servers to be placed within the network or at the end-points. When placed in the network, the SAW systems can directly control network resources (such as databases, switches, video servers, etc.) and provides network services. When placed at an end-point the SAW system becomes a client of another SAW server and/or can be a server itself for controlling devices on the end-points of the network.
We hope to deploy the SAW architecture in what is termed contained offerings. These are confined domains of thousands of customers such as cruise lines, resorts, and hotels. This would offer a high chance of success to introduce this approach and provide useful experience for future large scale network deployment.
We would like to acknowledge the following departments and individuals for their support and contributions to the implementation of specific aspects of this work including the assistance in execution of customer demonstrations. Harry Hall's Broadband and Photonics Switching Department, the members of the AT&T Solutions organization, Richard Dib and Steve Goss of the MMCU organization, the A-I-NET development community for establishing service creation as an important market for GPN and Haim Levendel for his support and leadership of this effort.
[AGH86] Agha, G., Actors - a model of concurrent computation in distributed systems, The MIT Press, Cambridge, Massachusetts, 1986.
[CHA94] Chandra, R., Gupta, A., and Hennessy, J.L., "COOL: An Object Based Language for Parallel Programming," Computer, pp. 13-26, IEEE, August 1994.
[DOU94] Duon, C., Henjum, O.I., Vadner, D.A., and Zurawski, L.W., "Comparison Study of Analysis Models Using ROOM and Shlaer/Mellor Object-Oriented Analysis Methods", AT&T Technical Memorandum, May 28, 1993.
[HAL93] Hall, R. J., "Validation of Rule-based Reactive Systems by Sound Scenario Generalization," Eight Knowledge-Based Software Engineering Conference, Chicago, September 1993.
[HAR87] Harel, D., "Statecharts: A visual formalism for complex systems," Science of Computer Programming, Vol. 8, North-Holland, 1987.
[KOW92] Kowal, J.A., Behavior Models: Specifying User's Expectations, Prentice Hall, 1992.
[LEE94] Ben Lee, and Hurson, A.R., "Dataflow Architectures and Multithreading," Computer, pp. 27-39, IEEE, August 1994.
[LEV91] Levendel, Y. "Reliability Models: Who Needs Them?" Fourth Reliability Conference, Invited Address, Denver-Colorado, 1991.
[NIE92] Nierstrasz, O., Gibbs S., and Tsichritzis D., "Component-Oriented Software Development," Communications of the ACM, special issue on Analysis and Modeling in Software Development, Vol. 35, No. 9, pp. 160-165, September 1992.
[SEL92] Selic, B., et al. "ROOM: An Object-Oriented Methodology for Developing Real-Time Systems," CASE 92 Fifth International Workshop on Computer-Aided Software Engineering, July 6-10, 1992, Montreal, Quebec, Canada.
[SEL93] Selic, B., "An Efficient Object-Oriented Variation of the Statecharts Formalism for Distribute Real-Time Systems," IFIP Conference on Hardware Description Languages and Their Applications, April 26-28, 1993, Ottawa, Canada.
[SEL94] Selic, B., and G. Gullekson. Real-Time Objet-Oriented Modeling, Wiley and Sons, 1994, ISBN 0471-59917-4.
[SHL92] Shlaer, S., and Mellor S. J., Object Lifecycles: Modeling the World in States, Prentice-Hall (Yourdon Press), ISBN 0-13-629940-7.
Video Service Construction from a Palette
ATTACHMENT 1
Expanding the Play Video Component
ATTACHMENT 2