System and method for presentation of cross organizational applications

A system and method for reducing complexity by reuse of programming models includes defining a model controller view (MVC) unit as a programming model abstraction in a first program and permitting access by a second program to a model in the MVC unit. The first program and the second program communicate to employ the model in the second program. Access of the model by the second program is responded to in the first program to execute an action.

BACKGROUND

1. Technical Field

The present invention relates to programming models and more particularly to systems and methods for providing models that unify several data models and related execution models in common use.

2. Description of the Related Art

In modern web applications, traditional boundaries between browser-side presentation logic, server-side “business” logic, and logic for persistent data access and query are rapidly blurring. This is particularly true in so-called web mash-ups, which bring a variety of data sources and presentation components together in a browser, often using asynchronous (“AJAX”) logic. Such applications must currently be programmed using an agglomeration of data access languages, server-side programming models, and client-side scripting models meaning that programs have to entirely rewritten or significantly changed to be shifted between tiers. The large variety of languages involved also means that components do not compose well without painful amounts of scaffolding.

While the trend towards loosely-coupled inter-networked software is inexorable, programming models and runtime systems are largely designed for building monolithic, freestanding applications. While the web has vastly increased the scale of distribution, web applications are currently programmed and deployed in a manner not that different from mainframe applications of the 1960s.

The mismatch between programming models/runtimes, and the predominance of inter-networked software is becoming a significant impediment to producing and composing reliable application software in a timely manner—and this mismatch is at the heart of much of the dissatisfaction developers have expressed with the complexity and obscurity of current middleware, programming models, and development tools.

SUMMARY

A system and method for reducing complexity by reuse of programming models includes defining a model controller view (MVC) unit as a programming model abstraction in a first program and permitting access by a second program to a model in the MVC unit. The first program and the second program communicate to employ the model in the second program. Access of the model by the second program is responded to in the first program to execute an action.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In accordance with the present principles, a simplified declarative programming model and runtime are provided which are expressly targeted at building and deploying cross-organizational software as compositions of web components. In addition, an evolutionary style of software development is supported that permits rapid application prototyping, but also enables progressive refinement of an initial prototype into a hardened asset. A simplified and uniform set of language features addressing end-to-end application design, including business objects, user interaction, and “last-mile” issues such as device adaptation, and multi-modal and multi-device interaction will be described. The programming language in accordance with the present principles may be referred to herein as “Collage” for ease of reference.

A single declarative language is provided to support enterprise, web and client applications, hence reducing complexity from multiple redundant abstractions. A resource description framework (RDF) based approach to the programming model used in accordance with the present principles does not impose encapsulation as strictly as in traditional object-oriented (OO) languages. Cross-organizational composition, and the attendant distribution of components, is easier using declarative data-driven programming models than using procedural or object-oriented languages. It should be understood that user interface (UI) elements described herein are illustratively shown using XForms. These elements are modeled here using e.g., RDF and participate in the Collage execution model.

Dealing with the constraints and variety of multiple end-user interaction devices has long been a challenge for user interface (UI) frameworks, whether web based or not. In accordance with the present principles, one contribution to this problem is to approach the problem as a reuse of a uniform set of concepts rather than as an ad-hoc framework addressed specifically to this “last-mile” problem, as has often been the case in the past. We apply the same language features introduced to support transformations and mapping among business objects, and between business objects and the UI, to support device adaptation as well.

Commonly assigned U.S. patent application Ser. No. 11/756,707 filed on Jun. 1, 2007, entitled “SYSTEM AND METHOD FOR MANAGING RESOURCES USING A COMPOSITIONAL PROGRAMMING MODEL” is hereby incorporated by reference.

Embodiments of the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment including both hardware and software elements. In a preferred embodiment, the present invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

A presentation and user interaction model in accordance with the present principles allows the description of user interfaces, or application “front-ends”, at a range of levels of abstraction. A recursive Model View Controller (MVC) pattern is supported, allowing the developer to refine an abstract user interface description through successive levels of more concrete specification.

Referring now to the drawings in which like numerals represent the same or similar elements and initially toFIG. 1, a recursive MVC model10is illustratively depicted. A model of an instance of an MVC pattern is represented by a resource12in accordance with the present principles. A view of MVC is a set of resources12,14,16associated with the model, whose instantiation is declaratively driven by the <c:create> construct. A controller of MVC is a set of <c:bind> constructs18that update the model resource12in response to updates to the view resources14,16, and vice versa.

The set of resources (12,14and16) that comprise a view of a model resource12may themselves serve as models for other views, thus supporting a recursive MVC pattern. The set of resources comprising a view, together with the <c:bind>-based controller18that connects the view resources14and16with the model resource12, may also be seen as a more concrete refinement of an abstraction represented by the model10. Conversely, the model10may be viewed as an encapsulation of the functionality provided by the view.

The present approach to presentation enables the description of user interfaces at a range of levels of abstraction. The progressive refinement towards the concrete user interface allows for separation of concerns during development. The ability to refine the presentation from higher towards lower levels of abstraction facilitates reuse.

Each instance of this MVC pattern is referred to as an abstract interaction unit. The development of a user interface as provided herein centers around abstract interaction units, and in particular, around the definition of the semantics of the class of an abstract interaction unit's model resource (12). The model class is given application-specific semantics by using it as the anchor class for a set of program constructs that define the semantics. A developer defines the class representing a composite abstract interaction unit by declaratively decomposing it into a collection of subordinate interaction units defined elsewhere. The developer also specifies controller logic that connects the composite and subordinate interaction units. At each level of the MVC recursion, the patterns representing the MVC concepts remain consistent. The classification of the composite interaction unit is used as the anchor class for aggregating constructs that create the subordinate interaction units and connect them to the composite interaction unit. For example, <c:create> is used to specify the creation of subordinate interaction units based on the classification of the composite interaction unit, and <c:bind> is used to specify the controller logic that connects the composite and subordinate interaction units. This uniform state and processing model eases refinement, adaptation and extension at each level.

A variety of composition patterns are supported in this way: In a typical composition pattern, a subordinate interaction unit is created corresponding to each piece of the model of the composite interaction unit that needs to be presented to the user or collected from the user. Collections of interaction units may be aggregated based on application semantics, constituting an abstract form. Interaction units may be designed with an eye to re-use, or they may be designed for a single use. The pattern described above supports either use case equally.

The MVC recursion is grounded in built-in abstract interaction primitives, such as c:INPUT, c:OUTPUT, and c:TRIGGER, each of which represents a primitive unit of presentation and associated reactive behavior. The abstract interaction primitives are discussed in greater detail below.

Necessary user interface layout information for each interaction unit is then specified in terms of an associated abstract layout tree. The layout tree comprises a set of layout containment triples whose predicate is a layout containment property, c:contains. Each layout containment triple connects: 1) An abstract layout container represented by the subject resource whose class indicates the style of layout. Examples of abstract layout container classes include c:VBOX (representing a vertical flow), c:HBOX (representing a horizontal flow), c:GRID (representing a tabular grid) and c:TOP (representing a top-level container, such as a window). 2) A containee, represented by the object resource. The containee may be either another abstract layout unit, or an abstract interaction unit as described above. Thus, the leaves of the layout tree are abstract interaction units.

Styling information is added similarly, either interspersed with layout information or separately per developer choice, using the Collage styling property c: style. The subjects in styling triples may be either interaction units or layout units, e.g., using RDF in one embodiment. Top level user interaction window resources have a c:TOP classification. An abstract layout tree is presented to the user by either connecting the root of the tree to a c:TOP resource via a containment triple (e.g., an RDF term), or by multiply classify the root of a layout tree as a c:TOP. Page flow is achieved by using classification and containment mechanisms to dynamically change the content of a top-level window.

Abstract interaction primitives: The present embodiments provide built-in abstract interaction primitives, which form the basis of the user interface or application “front-end” definition. The built-in primitives are illustratively modeled in RDF and each constitutes an abstract unit of user interaction, encapsulating an element of an abstract user interface. These built-in primitives are defined as resource classifications. The built-in set of primitives provides a common ground for development of various concrete user interfaces, such as for supporting different types of devices and interaction modalities.

An abstract interaction primitive specifies both the presentation of its model information to the user, and the response of the system to user interaction with the presented information, if any. This is achieved by having each of the resource classifications for these interaction primitives also specify the built-in dependent structure for that interaction primitive, and associating specific semantics with each resource within the dependent structure. For example, the c: INPUT abstract interaction primitive is used to collect a single piece of information, e.g., as an RDF literal. The dependent structure for c: INPUT, the application code that supplies its values, and a possible rendering are exemplified inFIG. 2.

Referring toFIG. 2, a c:INPUT primitive represents a simple one-line input field. A c:INPUT primitive includes three resources: 1) The c:INPUT resource22; 2) A dependent resource24connected to the c:INPUT resource by a c:label predicate; 3) A dependent resource26connected to the c:INPUT resource by a c:hint predicate. Furthermore, the following semantics are associated with this dependent structure: 1) The value associated with the label resource is to be presented to the user to indicate what response is desired for this unit of interaction; 2) The value associated with the hint resource is to be presented to the user when the user desires assistance with this unit of interaction; 3) The value of the c:INPUT resource at all times represents the current value of the input field as seen by the user. Thus, the value associated with the c:INPUT resource initially represents the default value of the input field, and subsequently represents the response from the user for this unit of interaction.

In the concrete rendering of the c:INPUT abstract interaction primitive shown inFIG. 2, a value28of the label resource appears alongside a textbox25and a value27of the hint resource is used as tooltip text for the textbox. A value29entered by the user in the textbox24becomes the value of the abstract interaction primitive resource. The refinement of the abstract user interface primitive to a concrete user interface is done using a renderkit, described hereinafter.

When the user enters a new value into the input field, the system responds by changing the value of the c:INPUT resource, which generates an update of the c:INPUT resource that in turn initiates an execution cycle. Thus, associated reactive behavior that is concerned with the value changes of the c:INPUT resource can be declaratively specified using <c:bind> constructs where one of its active inputs is the c:INPUT resource above. InFIG. 2, an RDF data model20is employed to distinguish data (value) from meta-data (non-value), e.g., value=“100 Oak St.” versus non-value (c:label, c:hint). Also, associated code21is shown.

A set of built-in primitives will now be illustratively described and provide a basis for a portable user interface definition in accordance with the present principles. This set of built in primitive is by no means a complete set of user interface elements. Indeed, an application may declaratively specify an additional set of resource classifications for other abstract user interface elements. These may be at the same user interface granularity as the built-in primitives, or be aggregations thereof.

Abstract presentation and interaction primitives:

In accordance withFIG. 2, a c:INPUT primitive represents a simple one-line input field. A c:INPUT primitive includes three resources: 1) The c:INPUT resource. The value of the c:INPUT resource at all times represents the current value of the input field as seen by the user. Thus the value associated with the c:INPUT resource initially represents the default value of the input field, and subsequently represents the response from the user for this unit of interaction. 2) A dependent resource connected to the c:INPUT resource by a c:label predicate. The value associated with the label resource is to be presented to the user to indicate what response is desired for this unit of interaction. 3) A dependent resource connected to the c:INPUT resource by a c:hint predicate. The value associated with the hint resource is to be presented to the user when the user desires further information for this unit of interaction.

Referring toFIG. 3, a c:TEXTAREA primitive represents a multi-line input field. A c:TEXTAREA primitive includes three resources: 1) The c:TEXTAREA resource32. The value of the c: TEXTAREA resource at all times represents the current value of the input field as seen by the user. Thus, the value associated with the c:TEXTAREA resource initially represents the default value of the textarea field, and subsequently represents the response from the user for this unit of interaction. 2) A dependent resource34connected to the c:TEXTAREA resource by a c: label predicate. The value associated with the label resource is to be presented to the user to indicate what response is desired for this unit of interaction. 3) A dependent resource36connected to the c:TEXTAREA resource by a c: hint predicate. The value associated with the hint resource is to be presented to the user when the user desires further information for this unit of interaction. A display39of the text area and accompanying code38are shown.

Referring toFIG. 4, a c:SECRET primitive represents an input field designed to collect information that should not be echoed in a readable form, such as a password. A c:SECRET primitive includes three resources: 1) The c:SECRET resource42. The value of the c:SECRET resource at all times represents the current value of the input field as seen by the user. Thus the value associated with the c:SECRET resource initially represents the default value of the secret field, and subsequently represents the response from the user for this unit of interaction. 2) A dependent resource44connected to the c:SECRET resource by a c: label predicate. The value associated with the label resource is to be presented to the user to indicate what response is desired for this unit of interaction. 3) A dependent resource46connected to the c: SECRET resource by a c:hint predicate. The value associated with the hint resource is to be presented to the user when the user desires further information for with this unit of interaction. A display49of the secret and accompanying code48are shown.

Referring toFIG. 5, a c:OUTPUT primitive presents a string to the user. A c:OUTPUT primitive includes three resources: 1) The c:OUTPUT resource52. The value of the c:OUTPUT resource represents the information presented to the user. 2) A dependent resource54connected to the c:OUTPUT resource by a c:label predicate. The value associated with the label resource is to be presented to the user to optionally qualify the information presented to the user. 3) A dependent resource56connected to the c:OUTPUT resource by a c:hint predicate. The value associated with the hint resource is to be presented to the user when the user desires further information for this unit of interaction. A display59of the output and accompanying code58are shown.

Referring toFIG. 6, a c:SELECT1primitive presents the user with a set of choices, and allows the user to select one of the choices. A c:SELECT1primitive includes four resources: 1) The c:SELECT1resource62. The value of the c:SELECT1resource at all times represents the current value of the select field as seen by the user. Thus, the value associated with the c:SELECT1resource initially represents the default value of the select field, and subsequently represents the response from the user for this unit of interaction. 2) A dependent resource64connected to the c:SELECT1resource by a c:label predicate. The value associated with the label resource is to be presented to the user to indicate what response is desired for this unit of interaction. 3) A dependent resource (not shown) connected to the c:SELECT1resource by a c:hint predicate. The value associated with the hint resource is to be presented to the user when the user desires further information for with this unit of interaction. 4) A dependent resource67connected to the c:SELECT1resource by a c:choices predicate. This dependent resource is connected to the individual item resources65by a c:item predicate. Each item resource describes one choice for the c:SELECT1primitive. The value of the c:SELECT1resource is at all times the value of the item resource chosen by the user at that time. Each item resource has a dependent resource61connected to the item resource by a c: label predicate. The value associated with this label resource is to be presented to the user to indicate what is being chosen by selecting the item. A display69of the selections and accompanying code68are shown.

Referring toFIG. 7, a c:SELECT primitive presents the user with a set of choices, and allows the user to select any number of the choices. A c:SELECT primitive includes four resources: 1) The c:SELECT resource72. The value of the c:SELECT resource at all times represents the current value of the select field as seen by the user. Thus the value associated with the c:SELECT resource initially represents the default value(s) of the select field, and subsequently represents the response from the user for this unit of interaction. 2) A dependent resource74connected to the c:SELECT resource by a c:label predicate. The value associated with the label resource is to be presented to the user to indicate what response is desired for this unit of interaction. 3) A dependent resource connected to the c:SELECT resource by a c:hint predicate. The value associated with the hint resource is to be presented to the user when the user desires further information for this unit of interaction. 4) A dependent resource76connected to the c:SELECT resource by a c:choices predicate. This dependent resource is connected to the individual item resources by a c:item predicate. Each item resource describes one choice for the c:SELECT primitive. The value of the c:SELECT resource is at all times the collection of the values of all the item resources78chosen by the user at that time. Each item resource has a dependent resource73connected to the item resource by a c:label predicate. The value associated with this label resource is to be presented to the user to indicate what is being chosen by selecting the item. A display79of the selections and accompanying code78are shown.

Referring toFIG. 8, a c:TRIGGER primitive includes three resources: 1) The c:TRIGGER resource82. 2) A dependent resource84connected to the c: TRIGGER resource by a c:label predicate. The value associated with the label resource is to be presented to the user to indicate what response is desired for this unit of interaction. 3) A dependent resource86connected to the c:TRIGGER resource by a c:hint predicate. The value associated with the hint resource is to be presented to the user when the user desires further information for with this unit of interaction. A display89of a trigger and accompanying code88are shown.

c:TOP: A c:TOP classification represents a top level user interface window. This includes: 1) The c:TOP resource. 2) A dependent resource connected to the c:TOP resource by a c:label predicate. The value associated with the label resource is to be presented to the user as the title for the top level window. The interaction units contained in this top level user interface window are connected to the c:TOP resource by c:contains predicates,

Example code for c:TOP includes:

A c:HBOX classification represents a horizontal flow layout container. The interaction units laid out in this horizontal flow are connected to the c:HBOX resource by c: contains predicates.

Example code for c:HBOX includes:

c:VBOX: A c:VBOX classification represents a vertical flow layout container. The interaction units laid out in this vertical flow are connected to the c:VBOX resource by c:contains predicates.

Example code for c:VBOX includes:

c:GRID: A c:GRID classification represents a tabular grid layout container. A c:GRID is used to display a series of records. When each record is displayed horizontally, as a row, the grid is said to be row-major. A row-major grid includes: 1) The c:GRID resource. 2) A dependent c:ROWS resource, connected to the c:GRID resource by a c:contains predicate. 3) Any number of c:ROW resources, connected to the c:ROWS resource by c:contains predicates. 4) An equal number of interaction units connected to each c: ROW resource by c:contains predicates.

Example code for c:GRID includes:

When each record is displayed vertically, as a column, the grid is said to be column-major. A column-major grid includes: 1) The c:GRID resource. 2) A dependent c:COLUMNS resource, connected to the c:GRID resource by a c:contains predicate. 3) Any number of c:COLUMN resources, connected to the c:COLUMNS resource by c:contains predicates. 4) An equal number of interaction units connected to each c:COLUMN resource by c: contains predicates.

Example code for c:GRID includes.

The set of built-in primitives provides a basis for a portable user interface definition, but is by no means the complete set of user interface elements. Indeed, an application may declaratively specify an additional set of resource classifications for other abstract user interface elements. These may be at the same user interface granularity as the built-in primitives, or be aggregations thereof. Furthermore, such classifications need to be declaratively specified once and may become reusable assets for many applications. The next section describes how this may be done in accordance with the present principles by defining composite abstract interaction units.

Composite Abstract Interaction Units:

An abstract interaction unit definition includes of the following elements as described and depicted inFIG. 1: 1) A model resource class that serves as an anchor class for the other elements of the definition. 2) A view, or set of subordinate interaction units, comprising the dependent structure of the abstract interaction unit. 3) A controller, defined by a set of program constructs such as <c:bind> that associate reactive behavior connecting the models of the composite interaction units and the subordinate interaction units.

Composite interaction units are built by aggregating existing abstract interaction units (either composite or primitive), while assigning them composite semantics. This process recurses uniformly to enable building interaction units that can abstractly specify larger units of interaction, potentially presenting many pieces of information to the user and collecting multiple responses from the user. For example, consider the unit of interaction for collecting calendar dates from a user. This could be defined as a new interaction unit whose model resource has class YMD. Associated with the YMD resource are three c: INPUT primitives, collecting the year, month and date respectively, as shown below in the illustrative code:

Referring toFIG. 9, a structure900associated with a YMD resource901that is created by the code above.FIG. 9shows that a model902for an interaction unit, that is the value of the YMD resource, includes separate elements for each of year, month, and day. This model value is expected to be provided by a user of the component (see example below). The ref attributes on the <c: create> construct bind the values of the c: INPUTs to the corresponding elements of the model, as indicated by the oval labeled “copy”.

This application may be an RDF-based MVC abstraction for a user interface design. We can now build on the YMD interaction unit to illustrate recursive composition of reusable abstract interaction units in applications that need to collect calendar dates. Consider, for example, an application that needs to collect dates in yyyy.mm.dd form. The application can build on the YMD interaction unit to define a new interaction unit, DATE-STRING, by providing the binds, or transformations, between the model of a calendar date associated with the YMD interaction unit and the model associated with a DATE-STRING interaction unit. This bidirectional transformation is expressed as a pair of binds in the following code:

Referring toFIG. 10, a DATE-STRING interaction unit1001and its relationship to the previously defined YMD interaction unit are illustratively shown as part of an XML program1000.

Layout and Styling:

The abstract interaction primitives and abstract composition units described above are abstract in the sense that they do not provide information about concrete rendering, such as the physical layout of the interaction units on a screen. This section describes the mechanism for overlaying concrete layout and styling information on the abstract interaction mechanism described above. The present embodiments provide a mechanism for describing a layout tree as an overlay on the abstract interaction units. A layout tree includes: 1) a set of resources connected as a tree by the Collage layout containment property c: contains; 2) a root node, such as a c: TOP resource representing a top-level user interaction window; 3) a set of interior nodes which are resources of a layout container class such as the built-in containers c:VBOX, c:HBOX, and c:GRID; and 4) a set of leaf nodes which are resources of one of the abstract interaction primitives described above (c:INPUT, c:OUTPUT, etc.).

The following example illustrates a simple layout tree for a login form. The layout tree is created by the following code:

Referring toFIG. 11, a layout tree1100created by the preceding code, and a rendering1102of that layout tree in a browser window are illustratively shown. In the layout tree diagram, the c: contains triples are shown as lines.

This layout tree includes: a top-level user interaction window represented by a c:TOP resource, which includes a horizontal flow represented by a c:HBOX resource, which includes a vertical flow represented by a c:VBOX resource, which includes a c:INPUT primitive, and a c:SECRET primitive, and a c:TRIGGER primitive.

The present embodiments provide a set of built-in layout containers: c:TOP, which represents a top-level user interaction window; c:HBOX, which represents a horizontal flow layout; c:VBOX, which represents a vertical flow layout; and c:GRID, which represents a tabular grid layout.

The layout tree1100can be specified as an overlay on the abstract user interface to provide a better separation of concerns between the abstract user interface definition and the layout tree and styling information for a concrete rendering of that interface. The following example illustrates such an overlay, and builds on the login form example above.

The LOGIN-FORM interaction unit is specified in terms of: The abstract user interface definition, which contains:A c:INPUT for the username (username input)A c:SECRET input for the password (password input), andA c:TRIGGER to submit the information (login trigger), andThe overlaid layout tree for the interaction unit, which contains:A horizontal flow represented by a c:HBOX resource, the root of the layout tree for this interaction unit, which containsA vertical flow represented by a c:VBOX resource, an interior node of the layout tree, which contains:The username input resource from the abstract user interface definition, a leaf node of the layout tree, andThe password input resource from the abstract user interface definition, a leaf node of the layout tree, andThe login trigger resource from the abstract user interface definition, a leaf node of the layout tree.

The layout tree1100for the login form is attached to a top level user interaction window, specified by the c:TOP resource. The separation of concerns between the abstract user interface definition and the layout tree and styling information is carried further in the following example, where the two have been factored into separate resource classifications, which may be defined in the same or different program units, by the same or different developers.

This approach allows for the possibility of specifying different styles for the same LOGIN-FORM, and choosing from among those styles either at the point in the code where the LOGIN-FORM is created (as in this example), or elsewhere in the code. By following this approach we have achieved a separation of concerns between abstract and concrete user interaction specification.

Renderkits: The preceding describes the mechanisms by which a developer defines abstract and concrete elements of a user interface. To present the user interface on any particular device, it must be rendered using a technology that may be specific to the device. A rendered user interface is implemented, in accordance with the present principles, as a refinement of the user interface described using the presentation primitives and layout mechanism described above. The resource classifications necessary for such refinement are defined in a renderkit.

Multiple classification is used to refine each resource classified as a presentation primitive into a resource that also contributes dependent structure and behavior towards the rendered user interface. The dependent structure and behavior are declaratively specified in the renderkit using <c:create> and <c:bind> constructs respectively.

The structure and behavior of the rendered user interface may be specific to a particular rendering technology. This may be accommodated by providing renderkits that are suitable to each rendering technology, such as (X)HTML, XUL, WML, VoiceXML, and so on. Since any given renderkit embodies just one approach to rendering for a particular technology, it is possible that there may be any number of renderkits for a given user interface technology. Each such renderkit might for example provide a different look and feel. It is also possible that a rendered user interface may be formed by combining features, such as resource classifications, from more than one renderkit.

Referring toFIG. 12, an illustrative diagram shows relationships between resources that are created by code that a typical application developer writes in area1202, a model1204, an abstract user interface (UI)1206, and a layout1208; and resources that are created by a renderkit1210, which most developers need not be concerned with. It is anticipated that most developers will not need or want to author a renderkit, but rather will use a pre-existing renderkit, such as a system-provided renderkit(s). However, it is possible that advanced developers might want to author a renderkit using the present programming model.

Each example is accompanied by a static screen shot of the example. This section introduces the present programming model through two examples that represent opposite extremes. The first example, the traditional “Hello World”, illustrates a minimal program for displaying a string to a user. The second example illustrates a complete (albeit minimal) end-to-end, potentially distributed, program that allows a user to view and modify information stored in a back-end database.

Referring toFIG. 13, a rendering1301of static text is shown. This example shows the simplest way to display static text. In keeping with the tradition for “Hello World” examples, it uses the most direct and concrete approach, embodying application logic, abstract user interface, layout, and styling all in one minimal set of resources, classifications, and triples. In later examples we will see how the present language allows these aspects of an application to be separated in a manner that promotes reuse and flexibility. InFIG. 14, a diagram1401illustrates the data structures and executable binds created by the code below.

InFIG. 14, Collage runtime automatically creates, for every new browser session, a new resource of class c:TOP, representing the top-level browser window for the session. The class c: TOP and associated behavior is defined by the Collage system, as indicated by its c: namespace prefix.

The hello-world application uses a <c:create> construct to create a c:OUTPUT resource and connect it to the c:TOP resource with a triple that has the c:contains property. The c:OUTPUT class is defined by Collage and represents an abstract user interaction primitive that presents a string to the user. The c:contains property is defined by Collage and indicates that the c:OUTPUT user interaction primitive is contained in the c:TOP window. The <c:out> construct provides an initial value for the c:OUTPUT resource created by the enclosing <c:create> construct. The initial value consists of the constant string “Hello World!”. The <c:out> construct is an example of a Collage bind, which is notated as an oval containing the bind expression.

This example is a simple end-to-end Collage application that provides a form (1) that allows querying and updating a database of weather information (2). It illustrates how a single declarative data and execution model is used uniformly through all tiers of a distributed application. This example briefly illustrates the use of three of the primary constructs of Collage: <c:create>, <c:let>, and <c:bind>. This example is intended just to show the scope and form of a complete end-to-end Collage application; the specific constructs used in the example will be explained in more detail by subsequent examples.

Referring toFIG. 15, a <c:create> construct is used to create and associate user interface elements such as inputs1503and triggers1504with a WEATHER resource class1501that represents the form:

A <c:let> construct uses the city-field input field to select a row from the database, recording it using the selected property:

A <c:bind> construct1506, triggered by the set trigger1504, updates the database with the quantity in the temperature input field, after converting Fahrenheit to Celsius. A similar <c;bind> construct retrieves the temperature from the database, converting Celsius to Fahrenheit.

FIG. 15gives no indication of the physical distribution of computing components, and the application code is largely independent of that. A typical deployment scenario is illustrated byFIG. 16, where the dashed boxes represent computing nodes.

Referring toFIG. 16with continued reference toFIG. 15, a database1502and a user interface1501might be provided by different computing nodes, that is, different Collage services. In this case the selected triple connecting the form to the database would create a distributed data structure, and the <c:bind>1506that updates the database would represent distributed program execution.

This section introduces basic concepts of Collage including, e.g., how to create resources, how to classify resources, how to connect resources with triples, how to assign values to resources, how to locate data using XPath, and how respond to value updates using bind.

Using Bind to Connect an Input Directly to an Output:

The example shown inFIG. 17shows how to create a c: INPUT resource and a c: OUTPUT resource, and connect their values using a <c:bind> construct. The resources are created using the <c:create> construct, specifying a class for the newly created resources, and the name of a property used to connect the resources to their anchor resource (identified as c:TOP). Every character typed into the input field generated by the c:INPUT resource cause the value of the c:INPUT resource to be updated, which triggers the execution of the <c:bind> construct. The <c:bind> copies the value of the c:INPUT to the c:OUTPUT.

This example illustrates a simple pattern in which an input is connected directly to an output. In subsequent examples, a more reusable pattern will be seen in which the constituent component models (the c:INPUT and c:OUTPUT values in this example) are connected via an additional data model specific to the aggregating component (represented by the c: TOP resource in this example).

Using a trigger to control bind execution: InFIG. 18, another example similar to the previous one in that it creates a c:INPUT whose value is copied to a c:OUTPUT is shown. However, unlike the previous example inFIG. 17, the c:OUTPUT is not updated on every keystroke. Text that is entered to the c: INPUT will be accumulated by the c:INPUT but will not trigger the execution of the <c:bind> because that input to the bind is marked passive. The c:TRIGGER resource is displayed as a button1801, and pressing that button1801will cause the c: TRIGGER resource to be updated, which will trigger the execution of the <c:bind> because the c:TRIGGER resource is an active input to the <c:bind>. The <c:bind> then copies the value of the c:INPUT resource to the c:OUTPUT resource.

Using bind to initialize the value of a resource: Referring toFIG. 19, another example shows how a newly created resource may be initialized using a bind. In the previous examples, binds were triggered by an update to the value of an input. In this example the bind has no inputs, and its execution is triggered by creation of its output resource. In this simple example the content of <c:bind> is a <c:out> which contains an XML structure1902representing the initial value of the resource that it targets, which is called its anchor resource, identified by its class c:TOP. The result is that the anchor resource is initialized with the value shown inFIG. 19, represented as an RDF value tree1901.

Thus we have seen that any bind may be triggered by an update to one of its input resources, provided that that input resource is marked passive=“false” (which is the default value if the passive attribute is not specified); or the creation of its output resource, provided that the bind is marked init=“true”.

Running this example produces no output in the browser, because the example does not bind the data to any user interface resources. You can observe the execution of the bind by viewing the console debug log.

Using XPath to locate data in a model: Referring toFIG. 20, this example shows how to locate data within a data structure using XPath. The data structure is first created with an initializing <c:bind>, as described in the previous example. The example then creates a c:OUTPUT resource to display the data. The ref attribute of the <c:create> binds the c:OUTPUT resource to the data that should be displayed and/or modified, as indicated by an oval2001marked “copy” inFIG. 20. The value of the ref attribute is an XPath expression that selects the data to be operated on. In this case, the expression is foo/bob, which means to first navigate from the anchor resource via a triple with property foo and then via a triple with property bob, arriving at the resource whose value in this example is “value of foo/bob”.

The function of the ref attribute is to bind the value of the resource identified by the XPath expression to the value of the resource created by the <c:create> construct that contains the ref attribute. Thus, the value of the foo/bob resource has been copied to the c:OUTPUT resource, which causes it to be displayed in a browser2002. Code2003is shown for implementing this.

Cascading binds: Referring toFIG. 21, this example shows how two or more binds may be cascaded, so that the resource value update that results from the execution of one bind triggers the execution of another bind, and so on. This example, like the previous example, creates a data structure, initializes it, and binds a c:OUTPUT to a portion of the data structure to display it. In addition, this example creates and binds a c:INPUT to the same portion of the data structure, allowing the user to modify the value of that part of the data structure. The ref attributes of each <c: create> bind the c: INPUT resource and the c:OUTPUT resource respectively to the data that should be displayed and/or modified, as indicated by the ovals marked “copy” inFIG. 21.

When the user types into the entry field, the value of the corresponding c:INPUT resource2101is updated. This results in the execution of the bind2102which updates the resource2103. The update of the resource2103triggers the execution of the bind2104, causing an update of the c: OUTPUT resource2105, which is displayed to the user. Code2108and a rendering2107of the output are shown.

User Interaction Basics:

This section introduces the basics of the Collage user interaction model, including primitive abstract units of interaction, concrete screen layout, modular design of user interfaces, and screen flow.

Using abstract user interaction primitives: Referring toFIG. 22, this example surveys abstract user interaction primitives defined by Collage. The interaction primitives themselves are abstract in the sense that their semantics is primarily focused on behavior, and their appearance as rendered on a screen rendering2202is specified only in general terms. For example, C:SELECT1specifies that a set of choices will be presented to the user, and the user will be provided with a means of selecting one of those choices. This primitive might be rendered in any number of ways: as a set of radio buttons, as a selection list, as a selection dropdown, and so on. Keeping the specification at a reasonable level of abstraction in this way promotes reusability. This example illustrates one possible rendering of these abstract primitives—in particular, the default rendering provided by the current Collage runtime system.

The primitives illustrated here, in the order that they appear on the screen2202inFIG. 22when you run the example, are:C:INPUT—allows the user to input a one-line stringC:OUTPUT—displays a string to the userC:TRIGGER—triggers an actionC:TEXTAREA—allows the user to input a multi-line stringC:SECRET—allows the user to input a secret string (such as a password)C: SELECT1—allows the user to select one item from a listC: SELECT—allows the user to select one or more items from a list.

Specifying screen layout: The preceding example illustrated a very simple screen layout2202including a set of interaction units arrayed one above the other within the top-level window, represented by the c:TOP resource. Collage provides a richer layout mechanism in which the developer describes a layout tree. A layout tree includes: a set of resources connected as a tree by the Collage layout containment property c:contains; a root node, such as a c:TOP resource representing a top-level user interaction window; a set of interior nodes which are resources of a layout container class such as the built-in containers c:VBOX, c:HBOX, and c:GRID; and a set of leaf nodes which are resources of one of the abstract interaction primitives described above (c:INPUT, c:OUTPUT, etc.).

The example ofFIG. 23illustrates a more complicated layout, including a login form structured as follows. In this figure lines are used as an abbreviation to represent c:contains triples. A top-level user interaction window2301represented by a c:TOP resource, includes a horizontal flow2302represented by a c:HBOX resource, which includes a vertical flow2303represented by a c:VBOX resource, which includes a c:INPUT primitive2304, and a c:SECRET primitive2305, and a c:TRIGGER primitive2306.

This structure is created by the following code:

This code tightly intermingles both the abstract design that there are fields for entering name and password and a trigger for submitting the information, and the concrete design which specifies how those elements are presented on a screen. The following example shows how to use Collage classification features to separate these abstract and concrete concerns.

Separating concrete from abstract user interaction: In the previous example, we defined login form with no separation of concerns between abstract and concrete design. In this example we see how to make this separation through a sequence of three refactorings.

Referring toFIG. 24, in a first refactoring, rather than directly filling the c:TOP top-level window with the login form primitives, we introduce the abstraction of a LOGIN-FORM2402, and fill the c:TOP top-level window2301with the LOGIN-FORM abstraction. The LOGIN-FORM abstraction in turn is filled with the login form primitives. As above, lines are used inFIG. 24as an abbreviation to represent c:contains triples. The accompanying code includes:

However, in the preceding, refactoring the LOGIN-FORM abstraction is still rather concrete in that it mixes concrete layout styling information with more abstract concepts. In the next refactoring as shown inFIG. 25, we take the step of separating the form into two parts: 1) The abstract part (represented by the solid parts) which specifies that there are fields for entering name and password and a trigger for submitting the information, gives the fields names in the form of application-meaningful properties (user name, password, and login) that can be used to navigate to the fields, and gives them defined abstract behaviors by specifying their abstract user interaction classes (c:INPUT, c:SECRET, and c:TRIGGER). 2) The concrete part (represented by the dashed parts), done as an overlay on the abstract part, which specifies how the abstract elements are arranged on a screen. Note that the LOGIN-FORM resource serves a dual role through its abstract classification of LOGIN-FORM and its concrete layout classification of c:HBOX.

The next refactoring is depicted inFIG. 26. The accompanying code includes:

In the preceding refactoring, we have separated the concrete code from the abstract code, but they still remain associated with the same class, which limits flexibiltiy. Now we take the final step of separating the concrete layout information into its own class LOGIN-STYLE-1. This allows us to separately specify the creation of the abstract LOGIN-FORM resource using <c:create class=“LOGIN-FORM”/> and the styling of that resource with the LOGIN-STYLE-1 style using <c:let class=“LOGIN-STYLE-1”/> The following code implements this separation.

The accompanying code includes:

This approach allows for the possibility of specifying different styles for the same LOGIN-FORM, and choosing from among those styles either at the point in the code where the LOGIN-FORM is created (as in this example), or elsewhere in the code. By following this approach we have achieved a separation of concerns between abstract and concrete user interaction specification.

Implementing screen flow: The preceding examples have presented static screens, in which the content of the screen—its layout, its entry fields, its buttons, and so on—do not change. Most substantial applications are implemented around a series of screens that are presented to the user one at a time, each focused on some task or subtask. The users actions determine which screens are presented and in what order. Many user interface technologies treat screen flow as a set of transitions among opaque states (where each state represents which screen is currently being viewed). The states are opaque in that they are simply names for the screens—“login screen”, “order screen”, “confirmation screen”, and so on, with no further expression semantics. The state transitions are expressed in terms of rules such as “when the order screen is showing and the user presses the submit button, transition to the confirmation screen”. This approach focuses on what transition to maker not why the transition is made.

While Collage supports this approach, it also supports and encourages an approach that is based more on why a given transition occurs. For example, in Collage the application might express rules such as “if the order is not in the submitted state show the order screen”, and “if the order is in the submitted state show the confirmation screen”. This approach will support more malleable applications because the rules operate independently of what path was taken to arrive at the conditions for displaying a particular screen. This means, for example, that the introduction of additional paths for arriving at a given set of conditions will automatically result in the display of the correct screen.

Referring toFIG. 27, this example illustrates a very simple page transition. It in effect embodies the following two rules: 1) If the user has not entered his name, display the screen for entering a name. 2) If the user has entered his name, display a screen greeting him. By expressing the page transitions in this way, if the application is enriched by an additional path by which the user's name is supplied (for example, by composition of this page flow with a larger application where the user has already entered his name), the display of the now-redundant screen requesting the user to type his name is automatically suppressed and the flow begins with the screen greeting the user.

This flow is represented by a top-level user interface container resource2701aor2701b, which the application has chosen to identify by a class “FLOW”. A FLOW container resource2702aor2702bcontains at any given time one of a number of child user interface resources, each representing a screen (2710or2712) in the flow. A <c:let> construct2711and2713for each screen (2710) and (2712) contains a conditional XPath expression that causes the corresponding screen to be created, configured, and displayed if its condition for being displayed is met. In this example, the condition is expressed by a test of whether a name has been specified. The resulting data structures for each of the two screens are shown inFIG. 27labeled2720and2722. The page flow may be conditioned on content of a top-level window, on declarative selection of top-level window content, on an RDF data model employed, an assignment of the RDF classification to the top-level window resource based on data model query. The code includes:

Composition: The Collage language features support modularity, reuse, customization, and composition. The examples used here relate to the user-interaction front end, but the same concepts are applicable end-to-end within an application.

Defining and using a reusable user interface component: Referring toFIG. 28, this example illustrates how to use Collage to build and use a reusable, customizable user interface component. This is illustrated by defining a reusable “date” component that allows the user to enter a date. The date component is defined as a Collage <c:unit> contained in the file ymd.xml. An instance of the date component is represented to the user of the component as a resource of class YMD. The date is stored in a model for the component that is the value of the YMD resource.

As component authors, we have chosen to represent the date as three separate fields in a screen rendering2801, for year, month and day. This is also illustrated inFIG. 29by the value triples, represented by heavy lines2901,2902, and2903, associated with a YMD resource2904.

Next, the date component defines an abstract user interface2910for displaying and entering a date, including three labeled input fields represented by c: INPUT resources. These resources are created and associated with every resource of class YMD by the following code from ymd.xml:

These resources define the user interaction at a relatively high level of abstraction: there will be three fields capable of displaying and entering three strings, and those strings will be bound to the yr, mo, and day fields of the component model (indicated by the ref attribute of the <c: create> construct). The date component also specifies some layout information that provides more concrete detail about the rendering of the date component. This is accomplished by the following code:

This code classifies the YMD resource with the additional class c:HBOX, which will cause the component to be displayed with a horizontal flow layout. The dual classification indicates that this resource plays two roles: the YMD classification indicates that the resource represents a particular composite interaction unit with its associated semantics, and the c:HBOX classification indicates that it has a horizontal flow layout. The code above also creates c: contains triples that indicate that the c:INPUT resources will be displayed within in the c:HBOX. Consistent with the dual role of the YMD resource, each c:INPUT resources is connected the YMD resource by two triples: 1) the yr-field, mo-field, and day-field triples are relevant to the YMD classification and indicate abstractly that the YMD resource aggregates the c: INPUT resources to form a composite interaction unit; and 2) the c:contains triples are relevant to the c:HBOX classification and indicate that the c:HBOX resource contains the c:INPUT resources in a horizontal flow.

The author of the date component has chosen to include this layout and styling information in a same compositional unit (in ymd.xml) illustratively shown inFIG. 30as the more abstract user interface elements, but as an alternative the author might have chosen to separate these two pieces of information into different compositional units. This would allow more flexibility in the layout and styling of the date component by a consumer of the component.

The compositional unit included in the file date-1.xml inFIG. 30creates a single instance of the YMD component by instantiating a resource of class YMD3002and assigning it a value representing a date to be displayed initially. The YMD resource is also declared to be contained in a c: TOP resource3001, causing it to be displayed as the top-level window content.

Adapting a reusable user interface component: Referring toFIG. 31, this example illustrates how to adapt the YMD user interface component described in the previousFIG. 30to have a different model, including a single string that stores the date in yyyy.mm.dd format, while preserving the same user interaction model of three separate date fields defined by the YMD component. This is defined by defining a new component, represented to the consumer of the component as a resource3102of class DATE-STRING. A date-string.xml compositional unit3101defines the user interaction model for DATE-STRING resources by delegating that interaction to a YMD resource3104. The value of the DATE-STRING resource is bound to the value of the YMD resource by a pair of <c:bind> constructs, one for transforming from DATE-STRING to YMD, the other for transforming from YMD to DATE-STRING. The value bindings are represented by the following Collage code:

The first <c:bind> construct is triggered by any change to the value of the YMD resource; it concatenates3112the three fields representing year, month, day and updates the DATE-STRING resource value with the concatenated values. This will happen for example on any user input to any of the three fields, meaning that the DATE-STRING resource is kept continuously consistent with what the user has typed so far.

The second <c:bind> construct is triggered by any change to the value of the DATE-STRING resource; it splits3114the DATE-STRING into three values representing year, month, day, and constructs a composite value representing the same information that becomes the value of the YMD resource. The composite value is constructed in XQuery as an XML document3106. This XML document is then interpreted as a set of triples with predicates yr, mo, and day that constitute the new value of the YMD resource. This bind will be triggered by any external programmatic change to DATE-STRING, for example in response to some form of user input in some other portion of the program as indicated in screen3110.

Customizing a reusable user interface component: Referring toFIG. 32, this example illustrates how to customize the DATE-STRING component described in the previous section to include an additional field that displays the date as a single date string, in addition to the three fields individually displaying the year, month, and day. This is accomplished simply by declaring an additional c:INPUT3202anchored to the DATE-STRING resource3204, and binding its value to the value of the DATE-STRING resource3204. The ref attribute specifies that the value of the c:INPUT resource3202is bound to the value of the DATE-STRING resource3204. As a result, any update to this new c:INPUT3202triggers the execution of a bind3206marked “split” inFIG. 32, which updates the value of the YMD resource correspondingly; and any input that updates one of the three fields of the YMD resource triggers the execution of the bind marked “conc” and therefore of the bind marked “copy”, which brings the value of the new c: INPUT resource into agreement with the new value of the YMD resource. This is accomplished by the following code:

Note that while this code in effect modifies the definition of the DATE-STRING class by associating additional dependent structure (the new c:INPUT resource) and new behavior (the binding of the values of the DATE-STRING resource and the new c:INPUT resource) with every resource of class DATE-STRING, this is accomplished without modification to the date-string.xml unit. This illustrates that class definitions—definition of dependent structure and definition of behavior associated with updates to resources of a given class—are orthogonal to compositional units. In this case the complete definition of DATE-STRING is split between the original date-string.xml unit and the new date-3.xml unit.

More Language Features:

This section shows how to use Collage beyond the basics for operating on collections, and to select data based on content.

Using “let” to work with collections: Referring toFIGS. 33 and 34, this example shows how to use <c: let> to work with elements of a collection. The example begins, as with previous examples, by initializing the value of the model using a <c:bind> construct. Unlike previous examples, in this example a collection including a set of repeated XML bob elements3401is created. Then, a <c:let> construct3400is used to iterate over the collection of foo/bob resources, creating a c:OUTPUT3402, a c:TRIGGER3403and a <c:bind> for each foo/bob of the model. Pushing one of the created c:TRIGGERs3302writes the data content of the corresponding foo/bob to a single c:OUTPUT3404defined outside of the <c:let> construct. The accompanying code may include:

The <c:let> construct in this example performs the following functions. Each foo/bob resource is classified as a BOB3401. This identifies the resources being iterated over. Each foo/bob resource is connected to the resource that identifies the containing component with an items property3408. This makes it possible to navigate from each BOB resource to the containing component, and from the containing component to each BOB. Note particularly that the <c:bind> construct uses the path items . . . /selected-bob to navigate from its BOB anchor to the single c:OUTPUT that displays the value of the BOB resource corresponding to that trigger. A set of resources3402,3403and binds (not shown) is created for each BOB resource by syntactically enclosing <c:output> and <c:trigger> constructs (respectively) in the <c:let> construct3400. This makes the BOB class the anchor class for the constructs, meaning that each such enclosed construct will generate one resource or bind (respectively) for each BOB resource.

Using XPath to selectively query data: Referring toFIG. 35, this example shows how to use XPath with a query to access a particular element from a collection. The collection in this example includes a set of resources each having a unique identifer id and some information data that is associated with the identifier. The accompanying code may include:

The above program also provides a c:INPUT field into which the user may type one of the identifiers. If the id of a foo/bob from the model data structure is entered into the c: INPUT the selected property is updated to point to the foo/bob whose id has been entered. Then, when a c:TRIGGER (not shown) is pressed, the corresponding data of that bob is displayed in a c:OUTPUT (not shown).

As mentioned above, the selected property is updated to reflect the resource selected by the current field. This is accomplished by the following <c:let> construct. The <c:let> construct specifies that for every resource R of class c:TOP, and for every resource S reachable by the specified path expression from R, a triple of the form [R selected S] is created. When the program state changes such that S is no longer reachable via the path from R, the corresponding triple is removed by the system. This is shown in the following code and inFIG. 36.

Using the Collage functionality and features, many new applications can be supported. In one example, MVC units from one application may be employed in other applications. This is explained in greater detail below. The following examples of MVC designs may be implemented using RDF for a data model. The data structures in the FIGS. are preferably RDF. For example, square boxes are resources and lines are triples. This conventional has been employed throughout for consistency. The application of RDF is preferably employed for writing user interface programs.

Referring toFIG. 37, an MVC unit3702may be employed as a programming model abstraction. In one embodiment, a first user can employ MVC3702or portions thereof from another program as indicated in the following example. From a developer point of view, a first programmer writes program1defining MVC data structures therein (see e.g., the structure described inFIG. 1). A second programmer writes program2that employs an exposed model M1defined in program1. During operation, M1functions as an abstraction interface. Program1constructs the MVC data structure (MVC3702). Program1permits access to M1, and program2communicates with program1reading and writing M1. Program1responds to reads/writes of M1by taking further action, e.g., since M1is an interface resource information may be exchanged between program1and program2. The exposed model M1may be employed in developing a program or as a user interface.

It should be understood that in the examples program1and program2may be programs on a same machine at a same location, on different machines at different locations, or may be different parts of the same program.

MVC units3702may be employed as an encapsulation mechanism (“exposed model”) where program1permits access only to M1which is exposed. Other portion of the MVC3702may be restricted from access by other programs.

MVC units3702support recursive specialization. For example, referring toFIG. 38, an MVC3802may be created by program2. Program2may in turn define an M2abstraction interface using M1from program1. MVC units supporting recursive specialization may be used to implement a renderkit.

Referring again toFIGS. 11 and 37, a separate specification of a layout tree as an overlay on an abstract presentation description can be provided as indicated inFIG. 11. From a developer's perspective, programmer1writes program1defining an abstract user interface (FIG. 11), and programmer2writes program2defining a layout operational view. InFIG. 11, c:INPUT, c:SECRET and c:TRIGGER comprise the abstract user interface (UI) specified by program1, and c:TOP, c:HBOX, and c:VBOX are layout specified by program2. In operation, program1constructs the data structure representing abstract user interface (UI), and program2constructs overly (additional) data structures specifying layout. RDF classes may be employed for classification as a separate specification mechanism (see e.g., notations next to square boxes (e.g., c:TOP, LOGIN-FORM, etc., which represent RDF classes) inFIG. 11.

The RDF may also be employed as a choice of presentation style. In a classification embodiment, from the developer point of view, programmer1writes program1defining an abstract user interface (inFIG. 11). Programmer2writes program2defining a concrete appearance. In the operational view, program1constructs a data structure representing abstract user interface, and program2constructs overly (additional) classifications using RDF classes. For example, program1specifies resource R1(M1inFIG. 37) has RDF class c:DATE (meaning, abstractly, a user interface affordance for collecting a date). Program2specifies resource R1has RDF class c:CALENDAR (meaning the date selector is presented to the user as a calendar widget). In another embodiment, program2specifies resource R1has RDF class c:DATE-STRING (meaning the date selector is presented to the user as a simple text input field).

A deployment and distribution model will now be described. The unit of deployment in Collage is called a service. A service is a logical computing node, comprising 1) a root URL that identifies and locates the service, and is the base URL for all resources managed by the service; 2) a triple store that represents the runtime state of the system as a set of RDF triples; 3) a set of composition units, each defined by a <c: unit> construct. A service deployment description specifies a root unit, and the set of units loaded by the service includes the root unit together with all units recursively imported using the <c: import> construct; 4) a set of resources that are managed by the service. Each resource is identified by a URL that begins with the service's URL. A resource per se is just a point in a namespace, and therefore requires no intrinsic storage. All storage associated with a resource takes the form of triples whose subject or object is that resource. Storage allocation and deallocation happens at the triple level; therefore there is no need in Collage for a mechanism to destroy resources.

A service is described by a <c:service> construct included in a deployment descriptor. A deployment descriptor may include multiple <c:service> constructs, supporting the case of multiple logical computing nodes managed by a single physical computing node. For example, the following deployment descriptor specifies a single service with a root URL of http://example.com:8080/weather/ and a root unit consisting of the <c: unit> construct found in the file weather.xml. The codes includes:<c:deployment><c:service location=“http://example.com:8080/weather/”unit=“weather.xml”/></c:deployment>

Referring toFIG. 39, a diagram illustrates the Collage approach to application deployment and distribution. Distributed computation is achieved by the use of URLs that cross service boundaries. That is, a service with prefix URL prefix A may include triples whose resources are identified by URLs beginning with the prefix B of another service. If for example a <c: bind> construct has a path expression that uses such a triple, it may refer to input and output resources that are managed by different services. In this case a change to the value of a resource managed by one service might cause a change to the value of a resource managed by a second service, resulting in distributed program execution.

Each service is employed on a logical computing node3901. Each service has a URL that is the root of the URLs for all resources managed by that service. In the program code, a service runs one or more compositional units3902, which includes a root unit and all recursively imported units. Each compositional unit3902defines at least partially a set3903of classes, properties and binds.

Runtime data includes a set of resources3904. Each resource (box) is a point in a namespace (e.g., a namespace of URLs prefixed by the service URL). Resources3904are programmatically created, and are dynamically and multiply classified (3905). A triple store3906includes RDF triples that associate data with resources and resources with each other to form data graphs and trees. Triples are programmatically created. Resources references3907may cross service boundaries, and therefore may cross computational node boundaries.

Employing this approach to distributed applications needs a strategy for associating triples with services, including replication of shared state across services, based on the URLs of the subject and object resources. In addition, efficient implementation protocols are needed. In one instance, for example, the execution of a bind can be accomplished, at a protocol level, by an appropriate HTTP POST.

Protocol: The Collage protocol that supports distributed Collage program execution may be defined as a set of XML message elements. The message elements are batched in a message envelope to allow more efficient communication. The message envelopes are transmitted as the request and response payloads of HTTP post requests directed at the service URLs. For example: <envelope cascade=“cascade-id” state=“cascade-state”> message elements </envelope>.

A message envelope includes a set of message elements relating to a particular cascade, identified by a globally unique cascade identifier that is allocated at the point of origin of a cascade. Each cascade is in one of a set of states defined by the execution model. The state attribute identifies the state of the current cascade, allowing distributed services to remain in sync with regard to the processing of a cascade. Permissible states include PROC_LET, PLAN_BIND, EXEC_BIND, and FINISH.

A <listen> message is in effect a request to subscribe to the value of a given resource. It instructs the receiving service to inform the sending service of updates to the value of the specified resource by sending <update> messages. For example, <update init=“init-flag” url=“resource-url”> new resource value </update>.

An <update> message informs the receiving service of a new value for a given resource. The value is transmitted as a list of XML child elements, representing the new value tree for the specified resource. The init flag, if set to true, specifies that the given resource is a new resource and may be initialized by a bind that targets the resource and has an init flag set to true. For example, <added s=“subject-url” p=“predicate-url” o=“object-url”/> <removed s=“subject-url” p=“predicate-url” o=“object-url”/>.

An <added> or <removed> message specifies that a triple that is of interest to the receiving service has been added to or removed from the triple store3906of the sending service.

A <status> message is sent in response to one or more of the messages described above to inform the receiving service of whether the sending service has further binds or lets to process. The receiving service uses this information to determine when the outer iteration loop of the execution cycle may terminate. For example, <status binds=“binds-flag” lets=“lets-flag”/>

Browser model: Collage treats a browser as a Collage computing node, that is, a service, with possibly limited capability. In the current implementation, upon first contacting a service with an HTTP GET request, a browser is sent a bootstrap Javascript program whose execution makes the browser a limited Collage node, capable of managing resources related to the presentation of the user interface. After this initial bootstrap exchange further communication between the browser and the server is via HTTP POSTs using the Collage protocol outlined above. This is accomplished with an AJAX-style JavaScript Collage Engine4018(FIG. 40) running in the browser.

The browser is capable of initiating updates for resources related to user inputs, of receiving notification of updates to resources related to user outputs, and of receiving and displaying Collage value trees, represented as XML documents, that represent screen layouts. It is envisioned that portions of a Collage program may be compiled to Javascript and loaded into the browser for execution to create a more responsive user experience.

Referring toFIG. 40, a server4002has a Collage service running on it, while a browser4004is connected to the server4002. The browser4004itself is a limited-function Collage node. Upon connecting to the server4002, a c:SESSION resource is allocated representing that browser session. Application code4006specifies semantics for a model4008, abstract user interface4010, and abstract layout4012. System code renders this user interface4016in a browser-specific technology (in this example, XUL).

The Collage protocol infrastructure then maintains equality between the server and browser copies of the rendered user interface representation by sending Collage update messages4020, in both directions. Update messages4020are sent from the browser4004to the server4002representing user actions, such as input values and trigger presses, which initiate an execution cycle that is distributed between the server4002and the browser4004. This is facilitated by a Collage engine4018, which employs, e.g., Javascript. Update messages4020are sent from the server4002to the browser4004to inform of updates to the information to be displayed to the user, either as part of an execution cycle initiated by the browser in response to a user action in the browser, or as part of an execution cycle initiated elsewhere. The latter case is seen by the user at the browser as an asynchronous (relative to the user's actions) push of information to the browser.

This provides a programming model that supports bi-directional transformations, e.g., date concatenate/date split type interactions. In this case, the browser4004is a collage listener (i.e. speaks protocol) and an initial download of a listening engine to browser may be provided. A user interface (UI) and updates may be transmitted to the browser as the browser listens for changes to rendered RDF data structures, e.g., the communication between computing nodes is based on messages communicating changes in resource values, or based on the addition and deletion of triples to a triple store. The resources may include RDF resources, and values may be c:values.

The programming model supports sub-page updates without explicit programmer coding of messages between browser and server, and the communication protocol between the browser and server is preferably the same as the communication protocol between server nodes.