4                      Application Layer

4.1                 Application Layer Metamodel

Figure 26 gives an overview of the application layer concepts and their relationships. Many of the concepts have been inspired by the UML 2.0 standard [7], [10], as this is the dominant language and the de facto standard for describing software applications. Whenever applicable, we draw inspiration from the analogy with the business and application layer.

Figure 26: Application Layer Metamodel

Note:      This figure does not show all permitted relationships: every concept in the language can have composition, aggregation, and specialization relationships with concepts of the same type; furthermore, there are indirect relationships that can be derived as explained in Section 7.5.

4.2                 Active Structure Concepts

The main active structure concept for the application layer is the application component. This concept is used to model any structural entity in the application layer: not just (re-usable) software components that can be part of one or more applications, but also complete software applications, sub-applications, or information systems. Although very similar to the UML 2.0 component, our component concept strictly models the structural aspect of an application: its behavior is modeled by an explicit relationship to the behavioral concepts.

Also in application architecture, the inter-relationships of components are an essential ingredient. Therefore, we also introduce the concept of application collaboration here, defined as a collective of application components which perform application interactions. The concept is very similar to the collaboration as defined in the UML 2.0 standard [7], [10].

In the purely structural sense, an application interface is the (logical) channel through which the services of a component can be accessed. In a broader sense (as used in, among others, the UML 2.0 definition), an application interface defines some elementary behavioral characteristics: it defines the set of operations and events that are provided by the component, or those that are required from the environment. Thus, it is used to describe the functionality of a component. A distinction may be made between a provided interface and a required interface. The application interface concept can be used to model both application-to-application interfaces, which offer internal application services, and application-to business interfaces (and/or user interfaces), which offer external application services.

4.2.1              Application Component

An application component is a self-contained unit of functionality. As such, it is independently deployable, re-usable, and replaceable. An application component performs one or more application functions. It encapsulates its contents: its functionality is only accessible through a set of application interfaces. Co-operating application components are connected via application collaborations.

An application component may be assigned to one or more application functions, business processes, or business functions. An application component has one or more application interfaces, which expose its functionality. Application interfaces of other application components may be used by an application component. The name of an application component should preferably be a noun.

Figure 27: Application Component Notation

Example

Example 17: Application Component

4.2.2              Application Collaboration

An application collaboration specifies which components co-operate to perform some task. The collaborative behavior, including, for example, the communication pattern of these components, is modeled by an application interaction. An application collaboration typically models a logical or temporary collaboration of application components, and does not exist as a separate entity in the enterprise.

An application collaboration is a specialization of a component, and aggregates two or more (co-operating) application components. An application collaboration is an active structure element that may be assigned to one or more application interactions or business interactions, which model the associated behavior. An application interface may be used by an application collaboration, and an application collaboration may be composed of application interfaces. The name of an application collaboration should preferably be a noun.

Figure 28: Application Collaboration Notation

Example

Example 18: Application Collaboration

4.2.3              Application Interface

An application interface specifies how the functionality of a component can be accessed by other components (provided interface), or which functionality the component requires from its environment (required interface). An application interface exposes an application service to the environment. The same application service may be exposed through different interfaces.

In a sense, an application interface specifies a kind of contract that a component realizing this interface must fulfill. This may include parameters, protocols used, pre- and post-conditions, and data formats.

An application interface may be part of an application component through composition (not shown in the standard notation), which means that these interfaces are provided or required by that component, and can be used by other application components. An application interface can be assigned to application services or business services, which means that the interface exposes these services to the environment. The name of an application interface should preferably be a noun.

Figure 29: Application Interface Notation

Example

Example 19: Application Interface

4.3                 Behavioral Concepts

Behavior at the application layer can be described in a way that is very similar to business layer behavior. Also here, we make a distinction between the external behavior of application components in terms of application services, and the internal behavior of these components; i.e., application functions that realize these services.

An application service is an externally visible unit of functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment. The service concept provides a way to explicitly describe the functionality that components share with each other and the functionality that they make available to the environment. The concept fits well within the current developments in the area of web services. The functionality that an interactive computer program provides through a user interface is also modeled using an application service, exposed by an application-to-business interface representing the user interface. Internal application services are exposed through an application-to-application interface.

An application function describes the internal behavior of a component needed to realize one or more application services. In analogy with the business layer, a separate “application flow” concept is conceivable as the counterpart of a business process. Note that the internal behavior of a component should in most cases not be modeled in too much detail in an architectural description, because for the description of this behavior we may soon be confronted with detailed design issues.

An application interaction is the behavior of a collaboration of two or more application components. An application interaction is external behavior from the perspective of each of the participating components, but the behavior is internal to the collaboration as a whole.

4.3.1              Application Function

An application function describes the internal behavior of an application component. If this behavior is exposed externally, this is done through one or more services. An application function abstracts from the way it is implemented. Only the necessary behavior is specified.

An application function may realize one or more application services. Application services of other application functions and infrastructure services may be used by an application function. An application function may access data objects. An application component may be assigned to an application function (which means that the application component performs the application function). The name of an application function should preferably be a verb ending with “-ing”; e.g., “accounting”.

Figure 30: Application Function Notation

Example

Example 20: Application Function

4.3.2              Application Interaction

An application interaction describes the collective behavior that is performed by the components that participate in an application collaboration. This may, for example, include the communication pattern between these components. An application interaction can also specify the externally visible behavior needed to realize an application service. The details of the interaction between the application components involved in an application interaction can be expressed during the detailed application design using, e.g., a UML interaction diagram.

An application collaboration may be assigned to an application interaction. An application interaction may realize an application service. Application services and infrastructure services may be used by an application interaction. An application interaction may access data objects. The name of an application interaction should preferably be a verb.

Figure 31: Application Interaction Notation

Example

Example 21: Application Interaction

4.3.3              Application Service

An application service exposes the functionality of components to their environment. This functionality is accessed through one or more application interfaces. An application service is realized by one or more application functions that are performed by the component. It may require, use, and produce data objects.

An application service should be meaningful from the point of view of the environment; it should provide a unit of functionality that is, in itself, useful to its users. It has a purpose, which states this utility to the environment. This means, for example, that if this environment includes business processes, application services should have business relevance.

A purpose may be associated with an application service. An application service may be used by business processes, business functions, business interactions, or application functions. An application function may realize an application service. An application interface may be assigned to an application service. An application service may access data objects. The name of an application service should preferably be a verb ending with ­“‑ing”; e.g., “transaction processing”. Also, a name explicitly containing the word “service” may be used.

Figure 32: Application Service Notation

Example

Example 22: Application Service

4.4                 Passive Structure Concepts

Also at the application layer, we distinguish the passive counterpart of the component, which we call a data object. This concept is used in the same way as data objects (or object types) in well-known data modeling approaches, most notably the “class” concept in UML class diagrams. A data object can be seen as a representation of a business object, as a counterpart of the representation concept in the business layer. The ArchiMate language does not define a specific layer for information; however, concepts such as business objects and data objects are used to represent the information entities and also the logical data components that realize the business objects.

4.4.1              Data Object

An application function operates on a data object. A data object may be communicated via interactions and used or produced by application services. It should be a self-contained piece of information with a clear meaning to the business, not just to the application level. Typical examples of data objects are a customer record, a client database, or an insurance claim.

A data object can be accessed by an application function, application interaction, or application service. A data object may realize a business object, and may be realized by an artifact. A data object may have association, specialization, aggregation, or composition relationships with other data objects. The name of a data object should preferably be a noun.

Figure 33: Data Object Notation

Example

Example 23: Data Object

4.5                 Summary of Application Layer Components

Table 2 gives an overview of the concepts at the application layer, with their definitions.

Table 2: Application Layer Concepts