English (United Kingdom)

https://curated-unify.zendy.io/wp-json/zendy-region/v1/featured_content/oa?rat=en

https://curated-unify.zendy.io/wp-json/zendy-region/v1/highlighted_journal/

Global: Zendy Plus annual

Presents the access of premium content as premium feature

Premium Content

Presents the keyphrase highlighting as premium feature

Keyphrase Highlighting

Presents the summarisation as premium feature

Summarisation

Insights

Presents the pdf analysis as premium feature

PDF Analysis

Presents the zaia usage as premium feature

ZAIA

Global: Zendy Tools annual

Global: Zendy Free Plan

Global: Zendy Tools monthly

Global: Zendy Plus monthly

There is an architectural deficit in most rich client applications currently undertaken: In n-tier applications the presentation layer is represented as a single layer. This fits badly with business layers that are increasingly organized along Service Oriented Architecture lines. In n-tier systems in general, and SOA systems in particular, the client’s role is to combine a number of services into a single application. Lowlevel patterns, mostly based on MVC, can support the design of individual components, each one communicating with a particular back end service. No commonly understood pattern is currently evident that would allow these components to be combined into a loosely coupled application. This paper outlines a rich client architecture that addresses this gap by adding a client application layer. 1 ADDRESSING DIRECT COUPLING IN COMPONENT-BASED ARCHITECTURES A common problem in the design of a componentbased rich client application of any complexity is the absence of any well-defined way of connecting its constituent components together in a predictable and maintainable way without coupling those components directly to each other. The importance of decoupling lies in the reusability it confers on the component. Development projects often result in either (i) relatively decoupled components that are connected to each other by a large, ad hoc and difficult to maintain amount of glue code (also know as the Big Ball of Mud), or (ii) components that cooperate in a more systematic way, but as a consequence come to know a little too much about each other, and become coupled to the extent that they are no longer reusable beyond the context of the application. Assuming that the Big Ball of Mud is always to be avoided, then the main obstacle to a componentbased, rich client architecture is tight coupling between the components. Objects cannot operate as components unless they can function both independently from and in collaboration with other components. Current rich client architectures do not satisfactorily address this seemingly paradoxical requirement, and permit only a limited decoupling between components that still results in some direct coupling. So there remains an architectural deficit in which developers of rich clients have to work. To address this problem, this paper outlines an approach, called Application Model View Controller (AMVC), that breaks the presentation layer into an application layer and a component layer. In enterprise systems, the client code is typically represented as a single layer – the presentation layer. (For Internet-based applications a distinction is made between server-side elements and client-side elements, but this is a deployment distinction, rather than an architectural one.) For both desktop and Internet based rich-clients, this single layer has not been enough. Single-layer architectures tend to result in bundles of components, directly coupled to each other as required by the needs of the application. Breaking applications down into components does not in itself reduce the direct coupling between the resulting components. An explicit application layer, specifically designed to prevent direct coupling, is an essential ingredient in any successful rich-client architecture. In order to ensure the absence of direct coupling which is required to sustain a true component-based architecture, we need to address the features of 351 Lawlor B. and Stynes J. (2007). THE MISSING LAYER Deficiencies in Current Rich Client Architectures, and their Remedies. In Proceedings of the Second International Conference on Software and Data Technologies SE, pages 351-356 DOI: 10.5220/0001325803510356 Copyright c © SciTePress component-based presentation layer architecture that can lead to direct coupling: events shared between components, event data shared between components, and containment relationships between components. The following sections describe the AMVC architecture, which removes each of these causes of coupling between components. 1.1 The AMVC Component Abstraction The first step in defining a component-based architecture is to define the abstraction of the component itself. The AMVC architecture’s notion of a component is heavily influenced by the hMVC (hierarchical Model View Controller) design (and therefore on PAC of which it is a specialized case), even to the extent of using the same terminology. But the AMVC component abstraction diverges from hMVC in a number of ways. AMVC can be said to be a modification and an extension of hMVC since the AMVC architecture also incorporates an extra layer of indirection that hMVC does not possess. A summary of the precise nature of the differences between the two architectures is provided towards the end of this paper, after a fuller explanation of AMVC has been offered. An AMVC component is a Model-ViewController grouping (Triad) where the controller has a function beyond the coordination of events between the model and the view: It also directs events out of the triad to other triads. Components are organized into a hierarchy as in hMVC and controllers act as the point of contact between the triads. Each component has its own individual functionality, but in the context of the AMVC architecture, the component is abstracted as a Triad that, from an external perspective, is simply capable of receiving events, emitting events, and entering into a parent-child relationship with another triad. Another public aspect of a Triad is the view itself this will be described later. We now consider the way these components are organized into applications. 1.2 Two Layers – Two Activities We can identify two separate layers in the construction of a rich client using AMVC. The component layer is composed of independent and functionally specialized Triads. The model elements of these Triads typically communicate with particular services in an SOA, if they have any server-side functionality at all. The application layer consists of application-specific configuration information that links instances from the component layer without introducing coupling between these components. It is this absence of coupling that defines the AMVC architecture and represents its main value proposition. The work of developing a rich client application can be broken up into two activities that correspond to the two layers above: component development and application assembly. In the absence of direct coupling between the components, applications can be assembled by combining and re-combining components in different ways, re-using the same component types many times within one application, and achieving different results with each combination. To appreciate how this architecture provides for decoupling between components, it is important to understand the factors that lead to coupling in the first place. But in order to do that, we must first look at the different kinds of events defined by AMVC. 1.2.1 AMVC Event Types There are two kinds of events defined by AMVC: Component Events and Application Events, corresponding to the Application and Component layers. Within AMVC components, the Model and View elements typically communicate with each other by means of Component Events (implementations allow for views directly calling model for efficiency and simplicity– though not vice-versa). Some of these events are exposed outside the components as emitted events, or received events, or both. Note that Component Events should be distinguished from what we will here call widget events. The latter are well understood concepts of GUI programming and communicate low-level interface-specific events (e.g. 'button A has been pushed') to components. The component layer intercepts, interprets and combines these widget events into Component Events, which represent reusable business functionality for a specific service (e.g. 'List the Orders'). Application Events are described below. 1.2.2 Coupling Due to Event Sharing Event-passing is a common way for components to communicate. Although this can often be done in such a way that avoids the programmatic coupling of the communicating components, a form of coupling remains: the name of the event itself. If an event is passed from one component to another, the communicating components must have a shared understanding of what that event means. This ICSOFT 2007 International Conference on Software and Data Technologies

THE MISSING LAYER - Deficiencies in Current Rich Client Architectures, and their Remedies