Manageability of Autonomic Software Artifacts using Contracts and ...

Manageability of Autonomic Software Artifacts using Contracts and Traceability Maps Sven van der Meer1, Joel Fleck2, Martin Huddleston3, Dave Raymer4, John Strassner4, Willie Donnelly5 1

Telecommunications Software & Systems Group, Waterford, Ireland 2 Hewlett Packard Company, Bridgewater, NJ, USA 3 QinetiQ, Hants, United Kingdom 4 Motorola Labs, Chicago, IL, USA 5 Waterford Institute of Technology, Waterford, Ireland

1 [email protected], 2 [email protected], 3 [email protected], [email protected], [email protected], 5 [email protected]

4

Abstract. In this paper, we detail the use of the Design by Contract (DbC) paradigm, applied to the Technology Neutral Architecture (TNA). Furthermore, we demonstrate how specifications for contracts can be used to manage an Autonomic System, in combination with Policies and Processes. We introduce Traceability Maps as a tool enabling manageability of software artefacts of Autonomic Systems. The work presented is mostly based on four years work within the TM Forum’s TNA team. The goal of this paper is to provide the reader with extended guidelines and architectural patterns that will help to develop manageable autonomic software and communication systems. Since we tackle the problem from a technologically neutral angle, this paper will not prescribe a single new technology, but rather provide a means that allows for federating different technologies, each of which offers particular advantages at business and system levels. In particular, it enables business concepts and principles to drive system design and architectures. This may be further implemented using currently available distributed systems information technologies.

1. Introduction Autonomic Networking addresses a number of challenges [4] and provides new engineering principles [5] for the management of ever increasing communication networks and services. One principle, which in fact is re-emerging (i.e. from Open Distributed Processing, ODP, [18]), is to start the design of an architecture from a technology neutral perspective. We have demonstrated concepts for such a definition in [6]. In this paper, we focus on details of an application of the Design by contract paradigm within the technology neutral specification of an architecture, namely the TM Forums’ NGOSS architecture. The work presented shows, beside the actual TM Forum standard, joined research work of several industrial and academic research teams (for example Ericsson [7], HP and QinetiQ [8] and Motorola [9]).

Within the NGOSS1 Architecture, contract-based interaction builds from work done by ANSA2 and RM-ODP3 specifications as well as from current software technologies like Java. However, none of these have addressed the issue of different users requiring multiple tailored views of the same inherent contract4. Indeed, most preceding work has focused on the definition of programming interface aspects of interactions, thus focusing on the implementation and run-time concerns of software interaction. The NGOSS Architecture, using the vehicle of the NGOSS Contract with representation in each NGOSS Lifecycle View [13], moved away from this traditional focus to provide an interface definition mechanism offering end-to-end lifecycle traceability and linkage in addition to traditional functional programming interface definitions. This work on the NGOSS Contract lifecycle definition is being done by both the TMF Lifecycle & Methodology and Architecture Teams. The NGOSS Contract is the fundamental unit of interoperability in an NGOSS System. Interoperability is core concern for each of the four views defined by the NGOSS Lifecycle. For example, a contract is used to define a specification of a service to be delivered, as well as to specify information and code that implement said service. The NGOSS Contract is also used to monitor, administer and maintain the service and ensure that any external obligations of the contract (e.g., from an SLA5) are met, and to define what measures to take if they are violated in some way. An NGOSS Contract also defines how the service must be used (e.g., invoked). It is much more than just a software interface specification - it also defines pre- and post-conditions, semantics for using the service, links to policies affecting the configuration, use, and operation of the service, and more. In short, the NGOSS Contract is a way of reifying a specification of a service, and implementing the functionality of the service (including obligations to other entities in the managed environment). Thus, it must be viewed as being more than just a container of data or of a set of methods. The goal of this paper is to provide the reader with extended guidelines and architectural patterns that will help to develop manageable autonomic software and communication systems. Since we tackle the problem from a technologically neutral angle, this paper will not prescribe a single new technology, but rather provide a means that allows for federating different technologies, each of which offers particular advantages at business and system levels. In particular, it enables business concepts and principles to drive system design and architectures. This may be further implemented using currently available distributed systems information technologies. The 2006 MACE6 workshop [3] has presented the drivers and challenges of Autonomic Networking [4] and fostered an understanding of emerging principles for 1

NGOSS – New Generation Operations Systems and Software ANSA – Advanced Networked Systems Architecture 3 RM-ODP – Reference Model for Open Distributed Processing 4 contract (lower case spelling) refers to the general notion of design by contract, Contract and NGOSS Contract depict the contract as specified in TMF 053B and discussed in this paper. 5 SLA – Service Level Agreement 6 The 1st IEEE Workshop on Modelling Autonomic Communication Environments was part of MANWEEK 2006 (October 25-26, 2006, Dublin, Ireland); organised by the founder of the Autonomic Communications Forum (Radu Popescu-Zeletin, FhG FOKUS), the ACF Chair (John Strassner, Motorola Labs) and the ACF Academic Co-Chair (Willie Donnelly, WIT). 2

this new type of networks [5]. In [6] we have demonstrated concepts for the definition of a technology neutral perspective. In this paper, we present the latest version of the TM Forum’s technology neutral definitions of contract (NGOSS Contract). First, we provide a brief introduction of the Design by (DbC) paradigm. Second we explain the computational and engineering aspects of an NGOSS Contract. This is followed by the TM Forum’s definition of contracts, along with a discussion about the integration of the design by contract (DbC) principles into the NGOSS lifecycle methodology. We finish the paper by providing a discussion on how NGOSS Contracts can be used to produce traceability maps, which we believe are an important tool for manageability of software artifacts of an NGOSS system (the later one also know as an NGOSS solution).

2. Design by Contract The NGOSS Contract model is based on the Design by Contract [10] notion pioneered by Bertrand Meyer and the concept of contractually defined interfaces developed by Bellcore [11]. The principal idea behind this approach is that an object and its clients communicate using contracts. It should be noted that this original definition was focused on building reusable, object-oriented software components specifically, designing classes and class methods. DEN-ng and NGOSS have taken this idea and expanded it to cover the production of the requisite artifacts across all four stages of the NGOSS Lifecycle. For an extensive discussion of DEN-ng extensions to the DbC paradigm (such as behavior, state, exceptions) see [12] and [8]. The term “contract” is used for two reasons. First, there is a formal nature to the communication, which is reminiscent of a legal contract. Second, the contract (as originally defined) consisted of three main parts a) pre-conditions, b) post-conditions, and c) invariants. The client must guarantee certain conditions before calling a method, and the object must guarantee a set of properties after the method call. These are, of course, assertions, and are referred to as the pre-conditions and post-conditions of the contract. For a given set of code, if its pre-conditions can be satisfied and its corresponding post-conditions can be realized, then the code can guarantee how the two objects will interact with each other. An important corollary of the original DbC approach is that no “hidden” obligations are present – everything that is required is specified in the pre- and post-conditions of the contract. Please note that the extensions defined by DEN-ng and NGOSS define an additional set of obligations and benefits, such as those included by mandating the use of policy. It should be noted that such an approach does not guarantee a “successful” method execution; rather, it guarantees that the result of the method is predictable (including how to deal with runtime errors). The notion of an invariant, in Meyer’s original work, is best explained by way of analogy. The pre- conditions of a contract describe a set of properties that must hold whenever the method is called; the post-conditions describe a set of properties that the method guarantees when it returns. In contrast, an invariant defines a set of global properties of instances of a class which must be preserved by all methods of the class.

Therefore, the true power of pre-conditions, post-conditions, and invariants is that collectively, they specify the expected behavior of an object relative to the external system. Thus, any variation from the specified pre-conditions, post-conditions and invariants may result in unpredictable behavior. Note that recognizing unpredictable behavior and, more importantly, correcting said behavior is also very important; this is handled through an abstraction of the programming concept of “exceptions”. An exception occurs when pre-conditions have been fulfilled, yet the post-conditions or invariants cannot be guaranteed. This characterization of the behavior of a software component interacting with other software components thus resembles contracts in a third important way. Meyer described this as a notion of a set of obligations to users of the functionality of the contract, and the notion of a set of benefits that those users would derive from using that functionality.

3. NGOSS Contract The NGOSS Contract is the unit of interoperability within the NGOSS Architecture [1], supporting all phases of the NGOSS Lifecycle [13].

(1)

In comparison, an NGOSS Component is the unit of deployment, an NGOSS Process is the unit of functional sequencing, an NGOSS Policy is the unit of governance, and an NGOSS Service is a unit of manageability. An NGOSS Contract supports all phases of the NGOSS Lifecycle of its systems and components, connecting business, system, implementation, and deployment concerns [13]. Relationships between the NGOSS Contract and other artifacts are defined in the NGOSS Meta Model [14]. Business and System View specifications can be found in [15] and [16] respectively. 3.1. Computational Aspect7 The TNA computational aspect introduces the concept of NGOSS Components; interactions between NGOSS Components are defined by NGOSS Contracts. The semantic and operational relationships between NGOSS Components are specified within an NGOSS Contract. Figure 1 shows the general concept of contracts and components within the NGOSS Architecture. A component contains the implementation of one or more contracts. Each of these contract implementations is exposed externally to the component via an interface. Components can be assembled into (sub) systems (or groups), whereas in this case the (sub) system has internal (not visible to the outside) and external (visible to the outside) contracts. Information exchanged between the functionality contained within components is semantically and syntactically described by a contract. In other words, components are bound for the purpose of information 7

Computational and Engineering aspects relate to the Computational Viewpoint and Engineering Viewpoint defined for Open Distributed Processing (ODP). See [8] for details.

exchange by a contract. The binding between contracts can be implicit, e.g., realized by an underlying framework, or explicit, e.g., realized by special contracts. Policies, not seen in the figure, are used to govern the behavior of a contract.

Fig. 1. Contracts and Components

Note: Figure 1 shows two contracts for the communication between the functionalities supplied by Component A and Component B. In fact, functionality contained within Component A is externally exposed via a contract and functionality contained within Component B is using this function, acknowledging the contract and expecting the functionality within Component A to behave according to the contract specification. Similarly, the functionality within Component A expects using functionality contained within Component B to behave according to the same contract specification. A contract-based interaction completes when a set of termination conditions associated to an invocation of the contract are reached. Figure 2 shows the general process of contract binding between two components. The purpose of an NGOSS Contract is to enable information to be shared between NGOSS Components. This includes the definition of how all types of data and knowledge is shared, including services, resources, and the behavior that is expected when one component participates in a contract with another component. This intercomponent behavior is expressed by a set of obligations and benefits. Mechanically, it includes the registering and invoking of functionality, using this functionality, and exchanging of information between the components. It also includes how the components in the contract communicate with other entities. An NGOSS Contract is designed to morph into different forms, having different content, based upon the NGOSS Lifecycle Views and the particular set of stakeholders that are using the NGOSS Contract at a particular time (cf. Figure 4). Note that this provides built-in traceability as well as documentation for how the NGOSS Contract evolves through the lifecycle of the solution.

Fig. 2. Computational Aspect - General Contract Binding

The NGOSS Contract, throughout each manifestation in the four NGOSS Views, supports information for that view, combined with information from other applicable phases, in a structured yet extensible form. Each NGOSS Contract supports information specific to an NGOSS View, association with information from previous Lifecycle Views, and information and data that document its functionality, its dependencies, and the environment in which it ‘lives’. An NGOSS Contract is made up of five parts (regardless of the NGOSS View in which it is being used): • The Generic Part consists of a standard header and a variable descriptive portion. It is common to all NGOSS Contracts for each view. − The Header Portion identifies each contract instance in an unambiguous way, and hosts a placeholder for a textual description of the NGOSS Contract. − The Descriptive Portion contains the goals of the contract, search criteria (facilitating discovery of contracts and contract instances), and description / comment fields. • The Functional Part of the NGOSS Contract defines the capabilities provided by the contract, constraints placed upon the use of those capabilities, and the context in which it can be used. The functional part can contain a variable number of fields, specific to the respective Lifecycle View. • The Non-Functional Part of the NGOSS Contract defines aspects needed for proper operation of the capabilities specified by the contract (e.g., security, management operations), as well as other considerations (e.g., cost). The functional part can contain a variable number of fields, specific to the respective Lifecycle View. • The Management Part of the NGOSS Contract defines the management requirements needed to operate the functional capabilities of the contract, assesses its resource and service cost, assigns QoS, describes geographic, resource, and operational constraints, and describes the legal constraints of the contract. • The Model Part of the NGOSS Contract contains various types of UML models to support the specification and description of the Functional and Non-Functional parts. This part supports the lifecycle management of the service, and any resources required to configure and maintain that service, in an OSS architecture. In a nutshell, it enables our approach to be self-documenting and self-describing. For specifications of NGOSS Contracts for the Business View and the System View please see [15] and [16], respectively. 3.2. Engineering Aspects An NGOSS Component is engineered following the rules of the Distributed Interfaceoriented Architecture (DIOA) as described in [1]. The functionality deployed via an NGOSS Component is represented by one or more NGOSS Contracts, thus an NGOSS Component is used to deploy one or more NGOSS Contract implementations. The Component Content Information Block (CCIB) is used to provide information about these contract implementations (most left part of Figure 3). One way of realizing a DIOA is using service-oriented architectural style, i.e. Service-oriented Architecture (SoA). Most of the engineering work within the TM Forum working groups is focused on SoA software development and system

engineering. An NGOSS Component implemented following the models of SoA offers 1 or more services via its CCIB (second part from the left in Figure 3). These SoA interface must realize a contract according to the general architecture (DIOA) and according to this document in order to be NGOSS compliant.

Fig. 3. NGOSS Component – DIOA, SOA and combined Engineering Aspect

An NGOSS service is supported by one or more NGOSS Contract implementations, which offer one or more distinct views to this very service. This is conform to the DIOA described in [1] and shown in the third part of Figure 3. Now we can design a combined model, which incorporates DIOA and SoA perspective of an NGOSS Contract, thus integrating design, engineering and implementation aspects of an NGOSS Contract. The most right part of Figure 3 shows this combined model. An NGOSS Contract implementation supports a service. One or more implementations can be available for a single service. A component, if engineered with SoA, contains one or more services and the service contract implementations are made available via the CCIB. 3.3. Integration with the NGOSS Lifecycle One of the distinguishing factors of the NGOSS program is its use of a methodology to govern the development of NGOSS styled solutions. The lifecycle as defined in GB927 [13] is a formalized specification for defining the characteristics and behavior of components. It also enables the interests of various stakeholders to be protected by representing the evolution of their interests as the solution progresses from the definition of its business concerns, through a mapping to a particular architecture and implementation, through its deployment. Specifically, the NGOSS Lifecycle contains two planes of interest (please see Figure 4), the Logical Plane (technological neutral) and the Physical Plane (technological specific). These planes intersect with the two perspectives of influence, the Service Provider Perspective and the Service Developers Perspective to yield the four NGOSS Lifecycle Views.

Logical View

Business

System

Business Capabilities, Constraints & Context

System Capabilities, Constraints & Context Corporate NGOSS Knowledge Shared Knowledge Base Base

Physical View

Deployment Deployment Capabilities, Constraints & Context

Service Providers View

Implementation Implementation Capabilities, Constraints & Context

Service Developers View

Fig. 4. NGOSS Lifecycle – Morphing Contracts

Thus, NGOSS is not just for developers or business analysts. NGOSS, rather, caters to a wide range of stakeholders that are concerned with different aspects of the problem throughout the entire lifecycle of an NGOSS solution. These stakeholders may be assigned specific responsibilities within the Lifecycle Views that represent the aspects of analyzing, designing, implementing and operating an NGOSS Solution. The NGOSS Lifecycle identifies the four views as the Business, System, Implementation, and Deployment Views. In the Business View, the eTOM [19] and the SID [12] are used to focus on the concerns of the business: processes, entities and interactions. The eTOM and SID work together to aid in identifying business processes and the information entities that support those business processes. The Business View represents the goals, obligations, and policies that describe the managed environment and the services that it provides in high-level, technology-independent terms. These various tasks and functions are modeled as interaction diagrams8 in which contracts are used to specify the behavior for how information is exchanged between collaborating entities. Significantly, these diagrams and additional supporting artifacts are collected and carried inside the contract, as will be discussed later in this document. In the System View, the SID, the eTOM, and the NGOSS Architecture are used to focus on the system concerns: managed objects, behavior, and computational interactions. The System View is primarily concerned with the modeling of system processes and information in a technology neutral manner. Additionally, interactions are used as above; the difference is that in the System View, contracts also specify the behavior for how the functionality can be used to exchange information between the collaborating entities in a technology-neutral manner. The Implementation View focuses on how to build hardware, software, and firmware to implement the system being designed. This view uses the NGOSS 8

A specification of how stimuli are sent between instances to perform a specific task. The interaction is defined in the context of a collaboration diagram.

architectural style to map the technology neutral specification of the solution to a particular target architecture. This mapping may include the use of available off-theshelf solutions. Again, interactions are used as before; the difference being that contracts will now also contain the implementation artifacts, such as code, technology specific interface definitions, APIs, or Web Service invocations. Finally, the Deployment View is concerned with operating and actively monitoring the system to ensure that the observed behavior is what is expected – if not, then that behavior is adjusted appropriately using the behavior and control mechanisms: process and policy based management. Once again, interactions are used to specify the details of the desired behavior. Thus, deployment contracts can contain a wide range of data (e.g., statistical performance data to evaluate the performance of the solution, policies to define specific behavior in response to particular stimuli, etc.). The advantage of this approach is that it provides traceability from the business definition and understanding of the solution through its architecture, implementation and deployment definition stages. An NGOSS styled approach also enables the information and data entities to be refined and extended through further development as each part of the development process is being worked. The functionality specified by an NGOSS Contract is expressed differently in order to reflect the needs of a particular constituency (e.g., the business analyst vs. the programmer), organized by the purpose of each particular view. This means that an NGOSS Contract has its own lifecycle, enabling the description, specification and implementation of its functionality to evolve during each phase of the solution; specifically: • The Business View of an NGOSS Contract specifies high-level goals and obligations that a resource and/or service must supply. This is done using concepts and terminology appropriate for communication and understanding by business personnel. • The System View of an NGOSS Contract specifies the architectural requirements necessary to design the contract, as defined by the Business View. This is done in a technical, though technology-neutral, manner appropriate for communication and understanding by the technical staff. • The Implementation View of an NGOSS Contract specifies the configuration, programming, and other implementation factors of the components necessary in order to provide the functionality specified by the contract. This is done using one or more technology-specific mechanisms, including vendor-specific products, devices, protocols, languages, and other artifacts as necessary. • The Deployment View of an NGOSS Contract specifies mechanisms for monitoring the performance, cost, and other aspects of the functionality delivered by the Component and for administering the contract to enable the contract’s activation and deactivation. This view contains artifacts to monitor the contractual obligations of the solution and to ensure that if those contractual obligations are violated, appropriate corrective action can and will be taken. It is convenient to think of the functionality of an NGOSS Contract in terms of a service (even though resources and other objects are required to deliver the functionality). The NGOSS Contract specification covers the functional and nonfunctional characteristics and behavior of a service, along with its goals and

obligations. Note that a contract can have different obligations to different stakeholders. All data exchanged in an NGOSS Contract invocation are defined using the SID, which enables information to be shared and reused. The needs of a particular constituency (e.g., the business analyst vs. the programmer) are accounted for by the use of a particular view, as previously explained. The SID supplies information entities for each of the views, and therefore supports linking them together. It is important to note that this provides traceability – information for one constituency is not lost, it is used as appropriate in other views. For complete definitions of basic constructs in TNA (Component, Service, etc), please refer to the TMF053 main document [1].

4. Contract Traceability Relationships – simple NGOSS Contracts can be defined for each of the Life Cycle Views. An NGOSS system can have one or more Business Contracts, one or more System Contracts, one or more Implementation Contracts, and one or more Runtime Contracts. This section explains the simple relationships of contracts defined for the same and/or different views. Business

System

Logical

1 to m where m >= 0

Business View Contracts (Concepts)

1 to m where m >=0

System View Contracts (Specifications)

1 to m where m >=0

1 to m where m >=1

Physical

m to 1 where m >=1

Run-Time View Contracts (Instances)

m to 1 where m >=1

Implementation View Contracts (Implementations)

m to 1 where m >=1

Run-time/Deployment Service Provider

1 to m where m >=0

Implementation Software Vendor

Fig. 5. Simple NGOSS Contract Traceability Relationships

The vast majority of contracts within a system will be directly traceable to requirements, however the practical reality of building large scale distributed computer based systems is one in which new concerns are introduced as the production of the system moves from the Business View to the System View and again as the system moves from the System View to Implementation Views. These

new concerns are called factors, a term taken from [17] and expended to cover not just architectural related concerns, but implementation related concerns as well. Factors are dealt with through the introduction of new requirements and constraints. Constraints are differentiated from requirements in that all requirements must be testable, whereas a constraint may not testable. Put another way, requirements are subjective and constraints are objective. All contracts within a system must be traceable to either a requirement or a constraint, both of which must be documented in a non-ambiguous fashion. Each of the contracts defined within a specific view can be related to each other. This means, a Business View Contract A can be associated (e.g. reuse functionality or specifications) of a Business View Contract B. Similar to this, an NGOSS Contract C defined for the System View can be associated to another NGOSS Contract D that is also defined for the System View. The same concept applies for the Implementation View and for the Runtime View. Each of the contracts defined within a specific view can be associated to another contract from another view by means of the following rules (Figure 5) according to the simple loop across the NGOSS Life Cycle Views that is show in Figure 4. The following characteristics of the relationships between NGOSS Contracts in the various NGOSS Lifecycle Views are established. • A Business View Contract is implemented by zero or more System View Contracts. This is useful as it allows for the introduction of steps in to a business process that must be performed manually (i.e., by a human being) rather than a computer-based system. • Conversely, a System View Contract can be related to zero or more Business View Contracts. This allows for the introduction of contracts in the System View as a response to factors identified during the specification of the System View. Note that this does not indemnify the newly introduced System View Contract from traceability requirements. All contracts, regardless of view must be traceable to either a contract from the previous phases, or a documented requirement and/or constraint. • A System View Contract is implemented by zero or more Implementation View Contracts. In a similar fashion to a Business View Contract with no System View manifestation, this is done to enable the introduction of tasks that can not be automated in the System View. • Conversely, an Implementation View Contract can be related to zero or more System View Contracts. This allows for the introduction of contracts in the Implementation View in response to factors identified during the specification of the Implementation View. As before, this does not indemnify the newly introduced contract(s) from traceability requirements. • An Implementation View Contract must be associated to one or more Runtime View Contracts. Note this is a departure from the pattern exhibited by Business View Contracts and System View Contracts. The Implementation View is a technology specific view, and as such any contract will have a deployable manifestation. • A Runtime View Contract might be associated to one or more Business View Contracts. This is logical consequence of the view-based approach to contracts

embraced by NGOSS. Note that this does not imply that every interface within the runtime view of a system will be defined by an NGOSS Contract.

5. Contract Traceability Relationships – complete NGOSS Contracts can be defined for each of the Life Cycle Views, that is, an NGOSS system can have one or more Business Contracts, one or more System Contracts, one or more Implementation Contracts, and one or more Runtime Contracts. Section 4 introduced a simple set of relationships between NGOSS Contracts defined for specific Life Cycle Views. This simple set, while allowing for simple traceability, might not provide appropriate functionality to define a complex NGOSS System. The following problems can occur while applying simple relationship rules: • A System View Contract may only be a partial specification of a Business View Contract; • A deployed Runtime Contract very likely only instantiates part of the functionality envisioned by a Business View Contract; • A deployed Runtime Contract may relate to multiple Business View Contracts. Each of the contracts defined within a specific view can be related to each other. This means, a Business View Contract A can be associated (e.g. reuse functionality or specifications) of a Business View Contract B. Similar to this, an NGOSS Contract C defined for the System View can be associated to another NGOSS Contract D that is also defined for the System View. The same concept applies for the Implementation View and for the Runtime View. Each of the contracts defined within a specific view can be associated to another contract from another view by means of the following rules (according to the simple loop across the NGOSS Life Cycle Views that is show in Figure 4:9 • A Business View Contract can be associated to System View Contracts in a 1 to m relationship with ⎧= 0, ⎪ m = ⎨> 0 and < 1, ⎪>= 1 and int, ⎩

if no associations to any SVC ,

(2)

if SVC is partial derivation of an BVC , if SVC is full derivation of 1 or more BVCs

That means that one System View Contract can either be a partial or a full derivation of a Business View Contract. Furthermore, a Business View Contract does not necessarily have to have a System View Contract associated to it, thus can not be implemented or deployed. • A System View Contract can be associated to Implementation View Contracts in a 1 to m relationship with

9

BVC = Business View Contract; SVC = System View Contract, IVC = Implementation View Contract, DRtVC = Deployment / Runtime View Contract

⎧= 0, ⎪ m = ⎨> 0 and < 1, ⎪>= 1 and int, ⎩

if no associations to any IVC ,

(3)

if IVC is partial derivation of an SVC , if IVC is full derivation of 1 or more SVCs

That means that one Implementation View Contract can either be a partial or a full derivation of a System View Contract. Furthermore, a System View Contract does not necessarily have to have an Implementation View Contract associated to it, thus cannot be implemented or deployed. • An Implementation View Contract can be associated to Runtime View Contracts in a 1 to m relationship with ⎧= 0, ⎪ m = ⎨> 0 and < 1, ⎪>= 1 and int, ⎩

if no associations to any DRtVC ,

(4)

if DRtVC is partial derivation of an IVC , if DRtVC is full derivation of 1 or more IVCs

That means that one Runtime/Deployment View Contract can either be a partial or a full derivation of an Implementation View Contract. Furthermore, an Implementation View Contract does not necessarily have to have a Runtime/Deployment View Contract associated to it, thus can not be deployed. • A Runtime View Contract can be associated to Business View Contracts in a 1 to m relationship with ⎧> 0 and < 1, m=⎨ ⎩>= 1 and int,

if R − TDC is partial derivation of a BC , if R − TDC is full derivation of one or more BCs

(5)

This implies that every Runtime View Contract must have an association to one or more Business View Contract, to allow traceability through all Life Cycle views for all deployed contract back to a Business View Contract.

6. Complexity of Contract Relationships and Traceability Maps This section takes the simple and complex relationships between NGOSS Contracts specified for different NGOSS Life Cycle Views and shows the complexity of the relationships. The meshed graph shown in Figure 6 represents a simple example of several NGOSS Contracts of an NGOSS System. Figure 6 shows all contracts of an example NGOSS solution for all views of the NGOSS Life Cycle with their dependencies. Dependencies are shown by directed lines (within a particular view) and non-directed lines (across two views). Dependencies across views can represent a full derivation (non-directed solid line) or a partial derivation (non-directed dashed line). A superscripted S represents a standardized NGOSS Contract specification. Following the allowed relationships, only Business View Contracts can be standalone, i.e. have no relationship to other contracts. NGOSS Contracts from all other views must have a relationship that can be traced back to at least one Business View Contract. For our example (Figure 6), we define:

• Business View: 6 contracts (B1-6), with for example B1 depending on B3 and B4 and the later two also depending on B1; • System View: 5 contracts (S1-5), with for example S2 not depending on any other contract in the System View but S3 and S4 depending on S2; • Implementation View: 4 contracts (I1-4), with for example I4 depending on I2; • Runtime View: 4 contracts (D1-4), with for example D3 and D4 depending on D2. System

Business

B1

Implementation

Run-time/Deployment

I1

S1

D1

I2

B2

D2

S2

B3

I4

S3

D3

B4 S N4 I3

B5

B6

S N5

D4

Contract Implementations

Run-Time/Deployment Contracts

Derivations (from SCs)

Derivations (from ICs)

Business Contract Definitions

System Contract Specifications

Dependencies (from ICs)

Dependencies (from R-TDCs)

Dependencies (from BCs)

Derivations (from BCs)

Dependencies (to ICs)

Dependencies (to R-TDCs)

Dependencies (to BCs)

Dependencies (from SCs) Dependencies (to SCs)

Fig. 6. Complexity of NGOSS Contract Relationships

The following derivations apply:10 • Business View to System View: 4 full derivations (B1 to S1, B4 to S3, B5 to S4, B6 to S5) and one partial derivation (B1 to S2); • System View to Implementation View: 3 full derivations (S1 to I1, S2 to I4, S4 to I3) and one partial derivation (S1 to I2); and • Implementation View to Runtime View: 4 full derivations (I1 to D1, I1 to D2, I3 to D4, I4 to D3). Now we can capture the associations of single contracts. We call this the NGOSS Contract Fingerprint, which provides information about: 1. a single contract and its relationships to other contracts from the same viewpoint or 2. a single contract and its relationships to other contracts from the same viewpoint and relationships to contracts from a prior viewpoint or 3. a combination of 1) and 2). Taking this representation into a linear form requires a number of symbols: 10

Note: relationships between Runtime/Deployment View Contracts and Business View Contracts are not specified in this example

=>

==

full derivation

->

==

partial derivation

;

==

separator of contracts of the same view

:

==

separator of contracts of different views

,

==

list of dependent contracts

^

==

dependency (of a contract of the same view)

(6)

With these symbols, the fingerprint of the Business View Contract B1, including all derivations across all lifecycle views, can be shown in a linear form: B1^B3,B4 : S1=>B1;S2->B1^S3,S4 : I1=>S1;I2->S1^I4;I4=>S2 : D1=>I1;D2=>I1^D3,D4;D3=>I4 We can also express the complete example of Figure 6 (i.e. all NGOSS Contracts and their relationships) using the introduced symbols in the following linear form: B1^B3,B4;B2^B1;B3^B1;B4;B5;B6 : S1=>B1;S2->B1^S3,S4;S3=>B4;SN4=>B5^S5;SN5=>B6 : I1=>S1;I2->S1^I4;I4=>S2;I3=>SN4 : D1=>I1;D2=>I1^D3,D4;D3=>I4;D4=>I3 The introduction and use of NGOSS Contract Fingerprints provides a resource to fill a key difficulty with many distributed architectures: the ability to automatically identify and select contract types based on desired capabilities and dependencies. Implementations of current distributed systems, while providing automatic selection of contract instance using traders and brokers once the desired contract type is known, do not facilitate the selection of the contract type. Indeed, contract type selection is almost always a manual process requiring scanning the textual descriptions of the registered contract types. The NGOSS Contract Fingerprint allows NGOSS System users to use the signature as a means of not only identifying the capabilities of an NGOSS Contract, but also to investigate the dependencies of the NGOSS Contract throughout the Lifecycle. A further benefit of the NGOSS Contract Fingerprint is that it enables the automatic comparison of multiple NGOSS Contracts. Automation of the contract type selection and comparison process also facilitates another key goal of the NGOSS Architecture: the real-time construction and composition of new services from already deployed NGOSS Contracts.

7. Managing Software Artifacts with Traceability Maps 7.1. NGOSS Use Cases11 A use case defines a sequence of actions that describe an agreement between stakeholders (anyone with an interest in or who is affected by the system) of an NGOSS system. The agreement can be seen as a description of the expected behavior 11

For a complete description of NGOSS use cases and templates please cf. [13]

of the system. Use cases can be nested into a hierarchy, which allows for the description of different scenarios. Stakeholders are identified by means of roles. A use case should always distinguish between a primary actor (stakeholder initiating an interaction) and other stakeholders. System behavior should always be focused on realizing the goals of all involved stakeholders. 7.2. Morphing Contracts It is convenient to think of the functionality of a contract in terms of a service (even though resources and other objects are required to deliver the functionality). The NGOSS Contract specification covers functional and non-functional characteristics and behavior of a service, along with its goals and obligations. Note that the same NGOSS Contract can have different obligations to different stakeholders. NGOSS supports all phases of the lifecycle of an NGOSS system and its components, connecting business, system, implementation, and deployment concerns. The mechanism for that is the concept of NGOSS Contract and its realization as a software artifact. The methodology for that is the support of evolution and morphing of NGOSS Contracts through the lifecycle phases. An NGOSS Contract expresses business and technical requirements of different stakeholders of an NGOSS system in a dynamic way. That means, contracts evolve and morph, meaning that contracts transform existing information according to the demands of the changing system environment. NGOSS Contracts provide a conceptual container in which static and dynamic aspects of a system can be stored. The DEN-ng information model enables the different views (static/dynamic and the lifecycle views) to be linked as a single cohesive whole. This enables the different actors and stakeholders to communicate with each other in a standardized form. [13] provides an example in form of an SLA. The SLA is written in business terms for business people to agree on. It will be technically represented by the business view contract. The following links needs to be established to realize this contract: • System View – how is the architecture affected, and can it support the goals and objectives set forth in the Business Contract? • Implementation View – how can the architecture be realized in hardware, software and firmware to implement this contract? • Runtime/Deployment View – how is the contract monitored to ensure that the SLA terms are not violated (and if they are, what corrective action should be taken). Dynamic contracts (evolution and morph) support the realization of this scenario. However, it is equally important to realize that policies, processes, and data will be dynamic as well. Contracts establish the current context for delivering a service. To ensure that changes in the context to not compromise the overall solution, it is imperative that policies, processes, data, and knowledge do not disappear or become disconnected. Morphing contracts provide the container to maintain the associations, providing visibility and traceability throughout all lifecycle phases.

7.3. Relationships between Software Artifacts Use cases describe a sequence of activities. Contracts, policies, and processes are software artifacts that can be packaged within a container, in order to realize one or more activities. Figure 7 shows that relationship, along with the associations between contracts (reference policies and processes, are controlled by policies), policies (control contract, select process, are adjusted by processes), and processes. package

package Policy

containedPolicySets 0..1

PolicyStatement

PolicyAction

PolicySet 0..n 1..n PolicyStatement i s used by PolicyCondition and PolicyActi on subclasses

policyConditionInPolicy Rule 1..n

1..n PolicyCondition

{ordered}

PolicyR ul e

PolicyGroup

1..n {ordered}

0..n

adjust

policyActi onInPolicyRule

1..n

controls

isTriggeredBy controlsExecutionOf 1..n 0..1

{filled in by triggerConstraints}

PolicyE ventSet

PolicyE vent

{filled in by executionConstraints} 1

{filled in by event Constraint}

0..n

hasEvents

NGOSS Policies package

Customer Strategy, Infrastructure Operations & Product Operations Strategy & InfrastructureProduct Fulfillment Assurance Billing Support & Commit Lifecycle Lifecycle Management Management

Readiness

Marketin g & Off er Management

Customer R elationshi p Management

Service Development & Managemen t

Service Management & Operations

Resource Developmen t & Management (Application, Com puting and Network)

R esource Management & Op eration s (Application, C om puting and N etwor k)

1

select

Business Contract

System Contract

2

Supply Chain D evelopment & Managemen t Supplier/Partner Relationship Management

Enterprise Management

Strategic & Enterprise Planning

references

Brand Management,Stakeholder & E xternal D isaster R ecovery, Market R esearch & Relations ManagementSecurit y & Frau d Advertisi ng Management

R esearch & Financial & AssetHuman R esources D evelopment, Management Management Technolog y Acquisiti on

Enterprise Qualit y Management, Process & IT Planning & Architecture

NGOSS Process Descriptions

NGOSS Containers

Deployment Contract 4

Implement Contract 3

NGOSS Contracts

OrderHandling TEAMDRAFT ©T eleM anagem entForumeT OMApril2001

define

Preorder Feasibility Determ ination

Credit Authorization

Order Issuance

OrderTracking andStatus

Order C om pletion

Custom er Satisfaction Validation

ReceiveP re-O rder FeasibilityRequest

Credit Investigation Determ ination

OrderRequest Validation

Status Establishm entand Managem ent

M anageC ustom er changesto Agreem entC on

ConfirmC ustom er Valuedelivery

IssuePre-Order FeasibilityStudy

Credit Investigation

OrderPlan Developm ent

StatusReport

Testsolutionand dem onstrateto cust

BillingSatisfaction Validation

ObtainAppropriate Approvals

OrderC reation

Custom er Jeopardy Notification

C onfirmOrder C om pletionwith C ustom er

Followupon optim alC ustom er Utilisation

Adviseand Negotiate AcceptableTerm s

OrderAm endm ent

Comm ittedD ate Re-negotiatiow/ Custom er

OrderCancelation

interfaces defined by reference

Trainthecustom er

Validateinfofor Assuranceand Billing Reportunm et com mitm entsor capabilities

package

NGOSS Activities

Fig. 7. Software Artifact Relationships

In other words, a formalized set of policies govern the behavior of each process and its interactions with its environment. A process defines the actions to be taken depending on environmental stimuli and each interaction is described by a contract. 7.4. Traceability Maps for Software Artifacts With the introduced use cases and relationships between software artifacts of an NGOSS system, we can make the following two, probably obvious, observations: • similar to contracts, policies and processes have presence in a Lifecycle View and • contracts, policies, and processes are linked in their specification That means we can provide an NGOSS Contract Fingerprint for each of these software artifacts. This will allow for a 2-dimensional view of the core software artifacts of a system throughout the complete lifecycle. Furthermore, we can use the linkage between the three software artifacts to build a 3-dimensional NGOSS Contract Fingerprint. This would allow to get a complete view of a system, allowing for instance to understand the impact of modifications within and between fingerprints of each artifact.

As introduced earlier, containers are used to package (or encapsulate) the software artifacts (for a detailed explanation please see [1]). The following encapsulations have been identified: • Services: contracts • Components: contracts (or services), policies • Applications: contracts (or services), policies, and processes These container artifacts are, to some degree, present throughout the lifecycle phases: • Application (in Business View), • Application Specification (in System View), • Application Implementation (or mapping to implemented components, policies and processes in the Implementation View), • Application Instantiation (or realization by contract instances and activated policies and process in Run-time/Deployment View). That means that a container can be represented by either its own fingerprint or by the equivalent (but more detailed) union of the fingerprints of its constituent software artifacts. As previously observed, use cases contain references to contracts, policies, and processes. Thus, we can extend the fingerprints to a full Traceability Map by following the references in each use case.

Container Software Artifact (Application, Component, Service) map between Container fingerprint and core software artifact fingerprints

Policy Bu sin ess

Syste m

Im pl em e n tati on

Contract

R untim e/ D ep lo ym e n t

Bu sin e ss

S ystem

Im pl em en tati on

Process

R un tim e / D eplo ym en t

reference

Bu sin e ss

S yste m

Im pl em e n tati on

R un tim e/ D ep lo ym e n t

reference reference to use cases and/or deployed system (not shown here)

Fig. 8. Management of Software Artifacts with Traceability Maps

Figure 8 shows all developed relationships. Clearly, there will be more than one contract, policy, and/or process fingerprint referenced by the map of a container artifact. Similarly, these fingerprints may be referenced by more than one container artifact. Use cases are also the genesis and driver of container artifacts, so we can close the cycle from the use cases, through the Traceability Map to the container

artifacts. The Traceability Maps provide the understanding and knowledge about the system to easy and fast answer many important questions helping the design and deployment of the very system, for example: • Is software artifact Y similar/comparable/related to software artifact X? • What are the duplicate software artifacts in the solution/application? • What are the gaps between the desired application and the delivering components? • What is the impact of one software artifact on another? • What other software artifacts is this software artifact (directly/indirectly) dependant upon? • What instances are related to each other (including ‘how’ and ‘why’)? • What software artifacts represent compositions? • What software artifacts are ‘composable’? The Traceability Map allows analyzing a system in two different ways. First, a static analysis will focus on software composition on either implementation time or integration time. Typical categories for this analysis are message flows, traffic volume, patterns of messages etc. Traceability Maps offer a tool to facilitate this process. Secondly, the usage of Traceability allows for a dynamic analysis, supporting real-time adaptability of autonomic systems and networks. Examples supported by Traceability maps include adaptation to an already occurred fault or other events to reduce and isolate the impact of this very fault (or event). Another example is that these maps can be used to predict a fault or event and prevent it from actually happening. Thus we consider Traceability Maps to be an important tool for facilitate both re-active and proactive dynamic analysis. Last not least, the Traceability maps can be combined for runtime information (current state, frequency of use, users, flow etc.) allowing for analysis of the impact of state changes, dynamic prediction of failures and bottlenecks, and reconfiguration of software artifacts and their relationships.

8. Conclusion In this paper we have introduced the specifications of architectural concept of NGOSS Contracts, based on the current TMF specifications. We have shown how NGOSS Contracts are integrated into the lifecycle of an NGOSS System. Based on these concepts, we have developed a description that allows identifying individual contracts within the context of a system’s contract definitions. We call the sequence of this an NGOSS Contract Fingerprint. In the last part of the paper we discussed some observations, which we then used to extend the concept of a single Fingerprint towards a complete Traceability map for a complete system. We are currently using the concept of a Traceability Map to: • Extend information models to include fingerprint for NGOSS software artifacts, • Develop tools to automatically generate fingerprints, • Develop tools to provide for automatic analysis of fingerprints and Traceability Maps (comparison, impact analysis, …),

• Develop simulation to demonstrate dynamic re-configuration of Traceability Maps, software artifacts and their states based on events/monitoring of run-time system, • Integrate Traceability Map with monitoring processes, and • Develop real-time analysis Traceability Map analysis tools. The goal of this paper was to provide the reader with extended guidelines and architectural patterns that will help to develop manageable autonomic software and communication systems. Since we tackle the problem from a technologically neutral angle, this paper provided a means that allows for federating different technologies. In particular, it enables business concepts and principles to drive system design and architectures. This may be further implemented using currently available distributed systems information technologies.

Acknowledgement Most of the work presented in this paper is based on the TMF Technology Neutral Architecture as described in the document TMF053 [1] and the NGOSS Contract specifications of TMF053B [2]. Sven is the current editor of both documents. Dave, John and Joel are Distinguished Fellows of the TeleManagement Forum, Joel is the leader of the Architecture Team in the TMF and all co-authors have actively contributed to the current version of the TNA. The authors wish to thank the members and contributors of the Architecture team and the Lifecycle & Methodology team for there contributions, discussions and patience. Part of this work has received support from the Science Foundation of Ireland under the Autonomic Management of Communications Networks and Services programme (grant no. 04/IN3/I404C).

References [1] [2]

[3]

[4]

[5]

[6]

TMF (Ed: Sven van der Meer): NGOSS Technological Neutral Architecture. TMF053, Ed. TNA Release 6.3 (NGOSS R6.1), Document Version 5.7, November, 2006 TMF (Ed.: Sven van der Meer): NGOSS Technological Neutral Specification - Contract Description: Business and System Views. TMF053B, Ed. TNA Release 6.3, Document Version 5.1, November, 2006 Willie Donnelly, Radu Popescu-Zeletin, John Strassner, Brendan Jennings, Sven van der Meer (Eds.): Modelling Autonomic Communications Environments. Multicon lecture notes, Vol. 2, October, 2006 Nazim Agoulmine, Sasitharan Balasubramaniam, Dmitri Botvich, John Strassner, Elyes Lehtihet, William Donnelly: Challenges for Autonomic Network Management. in Proc. of 1st IEEE Workshop MACE, Dublin, Ireland, October 25-26, 2006 Sven van der Meer, William Donnelly, John Strassner, Brendan Jennings, Mícheál Ó Foghlú: Emerging Principles of Autonomic Network Management. in Proc. of 1st IEEE Workshop MACE, Dublin, Ireland, October 25-26, 2006 Whitestein Autonomics Book

[7]

[8]

[9]

[10] [11] [12]

[13] [14] [15]

[16] [17] [18] [19]

Ray Carroll, Elyes Lehtihet, Claire Fahy, Sven van der Meer, David Cleary: Applying the P2P paradigm to management of large-scale distributed networks using a Model Driven Approach. in Proc. of 10th IEEE/IFIP NOMS, Application Session, Vancouver, Canada, April 3-7, 2006 Joel J. Fleck II, Sven van der Meer, Martin Huddleston: NGOSS Contract Fingerprints A Tool for Identifying and Facilitating Re-Use of NGOSS Contracts. TeleManagement World Americas 2006, Dallas, TX, USA, December 4-7, 2006 Ray Carroll, John Strassner, Greg Cox, Sven van der Meer: Policy and Profile: Enabling Self-knowledge for Autonomic Systems. in Proc. of 17th IFIP/IEEE Workshop on DSOM, Dublin, Ireland, October 23-25, 2006 Design by Contract, Eiffel software, www.eiffel.com/developers/presentations/ Bellcore: INA Cycle 1Framework Architecture (Issue 2): The INA Computational Model. TM-NWT-021896, December 1992, pages 3-11 to 3-13 TMF (Ed.: John Reilly): Shared Information/Data (SID) Model - Business View Concepts, Principles, and Domains. GB922, Ed. NGOSS R6.1, Document Version 6.1, November, 2005 TMF (Ed: Joel Fleck): The NGOSS Lifecycle and Methodology. GB927, Ed. NGOSS R6.0, Document Version 4.5, November 2004 TMF (Ed: John Strassner): NGOSS Architecture Technology Neutral Specification – Metamodel. TMF053D, Ed. TNA Release 6.3, Document Version 1.0, November, 2003 TMF (Ed.: John Strassner): Shared Information/Data (SID) Model - Business View Concepts, Principles: Addendum 1C: Business Contract. GB922-1C, Ed. NGOSS R6.1, Document Version 4.5, November, 2004 TMF (Ed: Dave Raymer): The NGOSS System View Contract– A Technical Report on Models and Methods. TR138, Document Version 0.2, May, 2007 Christine Hofmeister, Robert Nord, Dilip Soni. Applied Software Architecture. AddisonWesley Publishers, 1st Edition, November 4, 1999, ISBN: 0201325713 ITU-T Recommendation X.901 (1997): Information technology – Open Distributed Processing – Reference model: Overview. TM Forum: Enhanced Telecom Operations Map (eTOM) – The Business Process Framework. GB921, Version 0.3, Release 5.0, April 2005