A Service Oriented Architecture for Deploying and Managing Network Services.

Full text

Page 1

A Service Oriented Architecture for Deploying
and Managing Network Services
Victor A. S. M. de Souza and Eleri Cardozo
Department of Computer Engineering and Industrial Automation
School of Electrical and Computer Engineering
State University of Campinas
13083-970, Campinas, Sao Paulo, Brazil
{vsouza, eleri}@dca.fee.unicamp.br
Abstract. New generation network services must be deployed and man-
aged according to the specific customer requirements. In this context,
service providers must devise a way to design network services with near
zero time-to-market and high degrees of customization and evolution.
Customization is necessary to fit the service according to the customer’s
requirements, while evolution is necessary to adapt the service as soon
as these requirements change. In addition, customers are demanding the
ability to manage the service in order to keep the usage, configuration,
and evolution under their control. This paper presents an approach based
on service oriented architecture (SOA) for developing network services
able to fulfill the requirements of rapid deployment, customization, and
customer-side manageability. The approach considers the network ser-
vice as a set of interacting elements implemented as Web Services. The
service logic is expressed in terms of Web Services orchestration. A proto-
type for the management of connections in optical networks is presented
as a case study.
1Introduction
New network services differ from the present ones in many aspects. Firstly, the
time-to-market of the new services must be kept close to zero. In other words,
the time between the subscription for a service and its effective use must be very
short (ideally zero, no more than few hours in special cases). Secondly, the service
must take into account the exact customers’ requirements (and expectations)
such as aspects related to configuration, pricing, and quality. Finally, customers
are demanding the ability to manage the main aspects of the service in order to
take advantage of their business peculiarities, e.g., traffic patterns and end-user
profiles. Of course, price is always an important variable that can be reduced
as long as the complexities of service creation, deployment and management
decrease.
In this scenario, network providers must devise new ways of designing, deploy-
ing and managing network services. We strongly believe that service composition
is the key toward this objective. A network service can be created by composing

Page 2

a set of primitive services. This recurrent definition is important in the sense that
it allows a more complex service be built above a set of already existing services
such as back-end, resource management, and network management services. For
instance, a Virtual Private Network (VPN) service can be built by composing a
connection service, an authentication service, a fault management service, and a
resource management service. These composed services are distributed through-
out the service provider’s enterprise, some of them running on the central office
and others running close to the transport network.
Actually, there is a gap between the software entities at the business level
and at the network level. Entities at the network level are based on low level
signaling protocols such as RSVP-TE (Resource Reservation Protocol - Traffic
Engineering) and OIF’s UNI (Optical Internetworking Forum’s User-to-Network
Interface). The access to these protocols are performed via operator’s interface,
network management protocols (e.g. SNMP - Simple Network Management Pro-
tocol), or proprietary application programming interfaces (APIs). The entities
at the business level, on the other hand, rely on high level software artifacts
such as enterprise (e.g., EJB1, COM+2) components and web (JSP3, ASP4)
components. Clearly, the gap between the control and management entities at
network level and the entities at the service level is a complicating factor when a
network service with high level of automation and integration must be designed
and deployed in a short period of time.
Service oriented computing (SOC) is an attractive solution to narrow this
gap in the sense it offers a good level of automation, integration, customization,
and flexibility in service creation, deployment, and management. This paper
proposes a service oriented architecture (SOA) for management and deployment
of services in a connection oriented network. The architecture assumes that all
the composed services are Web Services and composition is governed by Web
Services orchestration and choreography techniques. In this architecture, service
creation consists in the edition of an orchestration script while the service de-
ployment consists in the installation of this script in an appropriated engine.
Service management is described via Web Services choreography, an interaction
agreement between different organizations or independent processes, in our case
service user and service provider. The edition of the orchestration script can be
assisted by specialized service creation tools or general purpose graphical editors
(as shown in this paper).
This paper is organized as follows. Section 2 discusses some related and re-
cently published works. Section 3 presents a brief introduction to SOC. Section 4
presents the proposed SOA-based architecture for service creation, deployment,
and management focusing on connection oriented networks. Section 5 presents
a prototype developed for assess the proposed architecture. Finally, Section 6
presents some closing remarks.
1Enterprise Java Beans
2Component Object Model
3Java Server Pages
4Active Server Pages

Page 3

2 Related Work
An important related work is being developed under the Canarie [1] User Con-
trolled LightPath (UCLP) Research Program [2], implemented and tested in the
Canadian research network CA*Net4. UCLP allows end-users, either people or
software applications, to treat network resources as software objects, provisioning
and reconfiguring them within a single domain or across multiple, independently
managed domains. This research explores new features and enhancements to the
current implementation of UCLP through the use of Web Services workflow
and orchestration to create “Articulated Private Networks”. The main design
features of this architecture are [3]:
– All network software, hardware, lightpaths and cross connects are exposed
as Web Services;
– Web Services workflow are employed to build a universal control plane across
instruments, lightpaths, cross connects, networks and software systems.
The work presented in [4] proposes Web Services as an embedded technology
for home appliances. The work argues that this is not an unrealistic assumption
as the price and capacity of embedded processors are becoming reasonable for
this application. This current work proposes the use of Web Services inside
network devices, based on the same arguments.
Similarly to the proposals presented in references [2] and [5] our architecture
give the customer the ability to manage a set of service parameters considering
customers’ specific needs. This feature will be provided in our architecture us-
ing Web Service choreography. Reference [5] gives the customers the ability to
build dynamically their application using a service trader. We are considering
a similar approach, but employing UDDI (Universal Description, Discovery and
Integration) instead.
3 Service Oriented Computing
Service oriented computing is considered by many a step forward in the dis-
tributed computing field. Distributed computing, mainly distributed objects and,
most recently, components, provide high cohesion, lower coupling, and modu-
larity to the applications. As a consequence, software reuse and evolution are
favored, with reduction of development and maintenance costs. Several open
standards for distributed computing such as CORBA (Common Object Request
Broker Architecture) and CCM (CORBA Component Model) from OMG (Ob-
ject Management Group), RMI (Remote Method Invocation) and EJB (Enter-
prise Java Beans) from the Java Community are mature and well accepted.
Software platforms supporting these standards are available, both commercially
and as open source software.
Unfortunately, these standards and platforms have not been used across en-
terprises. Security and interoperability issues are the most relevant reasons.
Protocols such as IIOP (Internet Inter-ORB Protocol) employed in CORBA

Page 4

and RMI are not “firewall friendly”, while the interoperability between differ-
ent standards has never been completely addressed. Moreover, loose-ends on the
standards may result in interoperability problems between platforms implement-
ing the same standard.
Was in this context that SOC emerged, providing a way to interoperate large
software entities, independently of software platforms and systems employed by
the enterprise. Service oriented computing is defined as “the computing paradigm
that utilizes services as fundamental elements for developing applications” [6].
Using orchestration mechanisms we can build a more comprehensive service that
can itself be part of a higher level composition [7]. The service workflow is defined
in orchestration scripts that is processed by an orchestration engine.
Some relevant characteristics of SOC reported in the literature are summa-
rized below:
– Interoperability - achieved through the use of an independent transport pro-
tocol.
– Composability - services can be composed to form another service, providing
a flexible, rapid and low cost way of creating new services.
– Reusability - being a modular unit of software, services generally can be
reused reducing the time and effort to build new applications.
– Ubiquity - services can be accessed from anywhere at the same time.
– Granularity - services presents higher granularity when compared with ob-
jects and components, facilitating the development of complex systems.
– Coupling - loose coupling is achieved in different levels:
– Just real dependencies among software elements are implemented as long
as each service has its own defined interface;
– Using registering and discovering mechanisms no coupling is made to the
service location;
– Platform and language coupling can be avoided using a platform indepen-
dent transport protocol;
– Synchronism due to the request-response invocation style can be attenu-
ated using asynchronous message exchanges.
We take advantage of these benefits to the design, deployment, and man-
agement of services in connection oriented networks such as optical and MPLS
(Multiprotocol Label Switching) networks. The most relevant consequence of
employing SOC in this field is a complete integration of the network and busi-
ness layers. This integration was proposed more than a decade ago in the scope of
TMN (Telecommunication Management Network). However, TMN never man-
aged to achieve such an integration due to the need of gateways (mediation and
adaptation functions in TMN) to connect software entities at different layers.

Page 5

4The Service Oriented Control and Management
Architecture
4.1Architecture Overview
In SOA every logical entity is seen as a service. New network services can be
assembled by orchestrating a set of existing services as shown in Fig. 1. These
existing services can be classified into two levels, the business and the network
levels. Services at the business level relate to the enterprise itself (e.g., subscrip-
tion), while services at the network level relate to the transport network (e.g.,
routing). As stated before, there is a gap between services located into these two
levels in terms of software entities the services are based on. A common approach
is to employ a gateway software that converts the high level business decisions
to the low level network signaling. This approach ties too hard the business and
network layers.
Fig.1. Proposed architecture.