![](bg8.png)
diagrams in which contracts are used to specify how
information is exchanged between collaborating
entities.
The System View is primarily concerned with
the modeling of processes and information that
affect the overall architecture of a component or a
solution in a technology neutral manner. The SID,
eTOM, and the NGOSS Architecture are used in
conjunction to focus on system concerns: managed
objects, the specification of behavior, and associated
computational interactions, again in a technology
neutral manner. Interactions are again used; the
difference is that in the system view, contracts also
specify how functionality is exchanged between
collaborating entities.
The Implementation View puts the focus on how
to build hardware, software, and firmware that will
implement the system being designed. This View
uses the particular NGOSS architectural style to map
from the technology neutral specifications of the
system to a selected target architecture. This drives
the customization of an appropriate DEN-ng data
model. Again, interactions are used; the difference is
that contracts also contain implementation artifacts,
such as code, APIs, or Web Service invocations.
Finally, the Deployment View is concerned with
operating and actively monitoring the system to
ensure that the observed solution behavior is what is
expected – if not, then the behavior can be adjusted
appropriately by using the NGOSS behavior and
control mechanisms of 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 evaluation
the performance of the solution, policies to define
specific behavior in response to particular stimuli,
and so forth).
This approach enables business, technology, and
product lifecycles of a given solution to be
synchronized. The advantage of this approach is that
it provides traceability from the business definition
of the solution through its architecture,
implementation and deployment. It also enables
information and data entities to be further developed
as part of the development process.
The DEN-ng lifecycle model uses contracts (
John
Strassner, 2004) as the “unit of interoperability”.
Contracts build upon the work done by ANSA as
documented in the RM-ODP specifications as well
as from current software technologies like Java.
However, the previous work has not addressed the
issue of different users requiring multiple views of
the same object, such as a contract. For example,
preceding work has focused on the definition of
Application Programming Interface (API) aspects of
interactions. This focuses on the implementation and
run-time concerns of software interaction, but
ignores its business and system aspects.
The NGOSS Architecture uses contracts in each
of the four views. This means that contracts are
always used to provide an interface definition
mechanism that links the business, system,
implementation and deployment aspects of a
solution together.
An important point is that the NGOSS contract
morphs as necessary to contain new and/or changed
information. For example, a contract in one view
could contain the specification of a service to be
delivered; that same contract in a different view
could specify information and code that implement
the service. Thus, a contract is more than a software
interface specification – it also defines pre- and post-
conditions, semantics for using the service, policies
affecting the configuration, use, and operation of the
service, and much more. In short, the 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).
5 CASE STUDY
A prototype of the NGOSS approach, including the
DEN-ng MDA code generator, has been
implemented and is being tested in a live Service
Provider environment. Its focus is to prove that key
provisioning tasks that result from a service order
can be modeled and, hence, automated.
In this test, various product offerings consisting
of rate-limited MPLS VPN services are used to
provide secure connectivity. The customer can
purchase different connectivity options, dictated by
the combination of the type of customer premise
equipment purchased, along with the number of
different services purchased (e.g., VoIP services in
addition to Internet connectivity) and their
respective QoS.
The MPLS VPN is modeled as a product offering
to ensure that the business policies and motivation
for the VPN, on a per customer basis, are properly
captured in the model. The DEN-ng product model
defines a Product as an aggregation of
PhysicalResources (e.g., a CPE device) and/or
customer-facing services. Thus, a VPN is a customer
facing service because the Customer is directly
aware of the VPN.
The PhysicalResources and customer-facing
services define logical resources (e.g., routing
processes) and resource-facing services (e.g., BGP)
that are used to ensure the proper operation of what
the customer sees. For example, the VPN may
A MODEL DRIVEN ARCHITECTURE FOR TELECOMMUNICATIONS SYSTEMS USING DEN-NG
125