The 4WARD deliverable D2.2 Draft Architectural Framework [pdf] is available for public review and comment.
A short summary of the content of this document and the 4WARD macroscopic architectural view (Stratum) and microscopic architectural view of network infrastructure and its resources can be seen off this link to the TSSG 4WARD blog.
With the Future Internet being envisioned as different network architectures coexisting and sharing a common infrastructure, we have been wondering here at the TSSG, well Patsy and Zohra specifically have been asking the questions of how these network architectures could/would/can be specifically tailored to a particular user or application requirement and can take into account the characteristics of the available networking resources and infrastructure.
We’ve looked and thought about a possible FI design processes, representing the workflow ranging from a business idea as a starting point to the design of network architecture models (NAM) and software architecture models (SAM). We’ve followed this with looking at the instantiation and operation of a network architecture fulfilling the detailed technical requirements derived from the business idea.
Given that we believe complex software design will have a big part to play in the realisation of this FI vision, Component Based Architecture (CBA) is an approach we have used to
To provide support for the development of systems as assemblies of components.
To support the development of components as reusable entities.
To facilitate the maintenance and upgrading of systems by customising or replacing
their components.
We have attempted to marry a design process with CBA in mind to define FI architectural components, their relationships and their functionalities, and to place these artifacts within a FI Design Repository.
In this way the component specifications (listing of contracts) of available components are stored within the design repository.
Why is this important? Patsy believes that the component contract forms the basis for interoperability and composition. The contract provides the formal mechanism by which interoperability between components can be measured. This interoperability then becomes the basis for composition as you can only compose components that are interoperable. The contract meta-data may also be used to construct anthologies of contracts and associated components, these anthologies when linked to functionalities such as QoS, mobility can be used to guide a designer from a functional requirement to possible contracts that fulfil the requirement and ultimately associated components.
At the higher abstraction level of Strata, CBA is providing the functional blocks (components) and units of interoperability (contracts) that can be used during the composition process. While at the CBA level is providing a link to development and deployment.
Okay this is the overview, some finer detail can be found in the deliverable D2.2