OSS Integration Best Practices

Document Sample
OSS Integration Best Practices Powered By Docstoc
					G Spice Consulting Ltd.


June 27th 2007

Wolter Jalink; Graeme Spice

Version 1.0

48 pages




           OSS Integration - a SOA approach




       www.ossprofessionals.com gspice@ossprofessionals.com tortuga_diver@yahoo.com
                                                                               Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                                                              Table of Contents


                                                                                                                              Wednesday, June 16, 2010




   TABLE OF CONTENTS

      Table of Contents .............................................................................................................. 1
      1         Introduction.............................................................................................................. 2
          1.1      Background .......................................................................................................... 2
          1.2      Objectives of the SOA based OSS Architecture ........................................................ 5
          1.3      Intended audience ................................................................................................ 6
      2         OSS SOA Architecture and Requirements .................................................................... 7
          2.1      Introduction.......................................................................................................... 7
          2.2      Overview of Service-Oriented Architecture based OSS ............................................. 7
          2.3      Conceptual Perspective.......................................................................................... 9
          2.4      Service Oriented Architecture ............................................................................... 15
          2.5      Enterprise Service Bus (ESB) ............................................................................... 17
          2.6      Distributed Interface Oriented Architecture ........................................................... 21
          2.7      Process Integration ............................................................................................. 21
          2.8      Human Interaction Integration ............................................................................. 22
          2.9      Technology Perspective ....................................................................................... 23
          2.10         Loose Coupling for Flexibility............................................................................ 26
      3         SOA based Architecture with Manager of Managers ................................................... 28
          3.1      Introduction........................................................................................................ 28
          3.2      High level Integration Design ............................................................................... 28
          3.3      Manager of Managers Integration ........................................................................ 30
          3.4      C-COR Cable-Edge Integration ............................................................................. 31
          3.5      Nortel Preside Integration .................................................................................... 32
          3.6      TeMIP Integration ............................................................................................... 33
      4         OSS Integration Roadmap – Gaining Business Value from SOA .................................. 35
          4.1      Introduction........................................................................................................ 35
          4.2      Phase 0 – Deploying the SOA Foundations ............................................................ 36
          4.3      Phase 1 – Fault Management and Performance Management ................................. 40
          4.4      Phase 2 – Configuration Management and Process Automation .............................. 42
          4.5      Phase 3 – OSS/BSS Integrations and Service Management .................................... 44
      5         Glossary ................................................................................................................. 46
          5.1      Definitions .......................................................................................................... 46
          5.2      References ......................................................................................................... 47
                                                         Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                               Introduction


                                                                                           Wednesday, June 16, 2010




   1 INTRODUCTION
      1.1 BACKGROUND
      Network and service management in the Telecom industry is inherently a distributed
      computing problem. In the past, the IT industry did not have a widely accepted distributed
      computing infrastructure adequate for the management task, so the industry developed
      various infrastructures of its own. Network management was initially performed according to
      a telemetry paradigm in which network elements sent a continuous stream of autonomous
      notifications to central monitoring facilities.


      Later technologies, such as SNMP and CMISE, utilized a manager/agent paradigm which
      added the possibility of remote intelligence and the ability for the central system to interact
      with and invoke operations upon the remote system. Although the notion of manager and
      agent will continue to be important for management, these technologies as implemented
      involved communication or management protocols that in the end were not adopted by the
      IT industry for general purpose distributed computing.


      The complexity of this IT environment in the Operational Suport Systems area (OSS) is often
      increased by mergers or acquisitions resulting in additional hard- and software platforms.


      Operators have initiated projects to improve network management, both on costs and quality.
      One major effort is focused on minimizing the number of network management tools to
      reduce complexity and the associated costs.


      Another major initiative focuses on a high level architecture and design for an improved
      network and systems management Service Orientated Architecture. This paper discusses the
      SOA network and systems management approach and the architectural considerations
      involved. The SOA framework avoids costly integrations based on different technologies and
      concepts. It is a means of achieving a high level of reuse, flexibility, while consolidating
      network management applications and tools. The discussed architecture enables integrations
      of OSS systems, not only within the realm of network and systems management but also with
      service and business management systems.


      The approach is focused on integrating existing systems using an Enterprise Service Bus and
      the concepts behind TMF NGOSS. In addition the approach should require minimal changes
      to the current infrastructure in order to avoid complete redesign of the NOC(s).


      The new architecture should be suitable to facilitate one central NOC for all operations across
      the network with a geographically diverse backup NOC. This document will present a concept
      network management architecture that incorporates an Enterprise Service Bus based
      integration of the network management tools in the OSS area and facilitates OSS-BSS
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                                Introduction


                                                                                            Wednesday, June 16, 2010



      integration. The architecture provides a basis for easier integration of future products,
      applications and functions.


      The same challenges arise at other large organizations outside the Telecom industry.
      Multinationals and government organizations have to manage complex infrastructures. This
      paper focuses on the Telecom industry but the key principles are equally valid outside the
      Telecom industry.



      1.1.1 CURRENT SITUATION
      Most current OSS environments contain a large number of IT tools related to network and
      systems management. With regards to the current OSS Architectures it should be noted that:
               There is a limited number of integrations between network management tools,
                primarily based on SNMP, or bespoke vendor licensed interfaces at a cost premium.
               There are custom built solutions to handle and dispatch SNMP and Syslog data to
                multiple systems (Log and Trap Exploders).
               Often several network management tools are being used to monitor the network.
               Most systems need to be integrated in order to exchange data.



      1.1.2 SERVICE-ORIENTED ARCHITECTURE PERSPECTIVE
      Operators need SOA based infrastructure to:
               Maximize use of current investment in IT solutions,
               Facilitate data exchange inside the OSS area and with the BSS area,
               Minimize changes needed in the current software,
               Enable changes in the IT environment without disturbing the business operation,
               Enable automated business processes that are loosely coupled with the systems used
                on task level.
      Operators want to implement a SOA with a vendor solution that is cost effective, lightweight
      and standards based. An Enterprise Service Bus is a concept that fits in this approach and is
      available from a number of vendors and even in open source. Therefore the ESB concept will
      play an essential role in the OSS SOA design. The ESB concept is explained in more detail in
      paragraph 2.5.
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                                Introduction


                                                                                            Wednesday, June 16, 2010




      1.1.3 TMF, NGOSS INITIATIVE AND OSS/J
      The presented architecture design is in line with the TeleManagement Forum NGOSS
      principles. Below is an overview of the NGOSS initiative and the organization behind it.


      TeleManagement Forum (TMF)
      The TeleManagement Forum is an international consortium of communications service
      providers and their suppliers. Its mission is to help service providers and network operators
      automate their business processes in a cost- and time-effective way.


      TeleManagement Forum‘s vision is ―to lead the emergence of lean and agile operators, able
      to compete in 21st century markets‖. The Lean Operator Program is thus TeleManagment
      Forum‘s flagship program and the New Generation Operating Systems and Software (NGOSS)
      technical roadmap is a key technical and process enabler of that program. The NGOSS
      Shared Information/Data (SID) model provides the a common vocabulary and set of
      information/data definitions and relationships used in the definition of NGOSS architectures.
      The eTOM Process Model is a reference for all the component processes needed to run an
      operator, and the Telecom Applications Map forms the 4th major framework that compromises
      NGOSS.


      Specifically, the work of the TMF includes:
               Establishing operational guidance on the shape of business processes,
               Agreeing on information that needs to flow from one process activity to another,
               Identifying a realistic systems environment to support the interconnection of
                operational support systems,
               Enabling the development of a market and real products for integrating and
                automating telecom operations processes.


      NGOSS Overview
      NGOSS is a comprehensive, integrated set of tools for defining, developing, procuring and
      deploying operational and business support systems and software. It is available as a
      packaged set of industry-agreed guidelines; maps; models; methodologies and specifications
      that cover key business and technical areas. These NGOSS tools, and the clearly defined
      methodology for using them, assist the user to define, design and build NGOSS compliant
      solutions that can easily integrate into any NGOSS compliant environment. As such, NGOSS
      delivers measurable improvements in development and software integration environments
      through use of standards, processes, reuse of components, and repeatable cycles.


      The NGOSS initiative aims to deliver a framework for rapid and flexible integration of
      Operation and Business Support Systems in telecommunications and throughout the wider
      communications industry. Key areas of the NGOSS initiative are:
                                                           Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                                 Introduction


                                                                                             Wednesday, June 16, 2010



               Definition of the Next Generation Business Process Framework,
               Definition of a standard set of Business Processes for the Information and
                Communications Services Industry,
               Definition of the Systems Framework upon which these business processes may be
                built,
               Practical implementations and live demonstrations of these solutions,
               Development of an industry compliance program to certify solutions and products for
                compliance to the NGOSS Specifications.
               Creation of a resource base of documentation, models, code and training materials to
                support the TM Forum members in their own development of NGOSS-compliant
                components


      OSS through Java™ Initiative
      OSS/J has been at the forefront of defining, in an open-standard fashion, OSS-specific APIs
      and design guidelines for mainstream technologies such as J2EE and XML. This work is based
      in part on the TeleManagement Forum's New                  Generation OSS (NGOSS) Shared
      Information/Data (SID) Model and represents an implementation view of the NGOSS
      architecture. OSS/J has now become a TMF Technical Program, composed of a working group
      of industry leaders committed to sharing experience, methodologies, ideas and artifacts
      supporting the widely adopted OSS/J telecommunications platform. The Initiative makes
      available, free of charge, technologies that significantly reduce integration costs (the single
      largest roadblock to profitability) while fostering more effective relationships between vendors
      and buyers.



      1.2 OBJECTIVES OF THE SOA BASED OSS ARCHITECTURE
      The following objectives are the basic fundaments on which the architecture is defined:
               Improving network management frameworks;
               Integrating current systems using a standardized approach and integration
                framework;
               Making minimal changes to current infrastructures, to avoid complete redesign of the
                NOCs;
               Consolidation of multiple NOCs to a centralized NOC;
               Maximizing the investments already made by reusing existing applications;
               Increasing agility by using a scalable standards-based solution.


      In a central NOC, responsible for the supervision of the network comprised of heterogeneous
      equipment and systems, a central system for monitoring and alarm handling is crucial. Events
      and alarms are to be collected from various sources inside the OSS area, transformed into a
      unified format and presented to the NOC Operator in the ―manager of managers‖ tool.


      The vendors of network management software are expected to provide well-defined
      interfaces to forward alarms, to retrieve performance data, to allow services to be
                                                         Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                               Introduction


                                                                                           Wednesday, June 16, 2010



      provisioned etc. In practice most interfaces are proprietary and complex. This has enormous
      impact on the possibilities and costs of integration and operation.


      A tool must be selected as the ―manager of managers‖ to perform this central monitoring
      function. The events are collected via SNMP traps, Syslog events, CMIP events or proprietary
      agents. The data feed can be enhanced, transformed and routed on a cost effective matter
      using an Enterprise Service Bus. The ―manager of manager‖ will receive this data from the
      ESB and process it accordingly.


      The network management solutions that do not already support standard data feeds into the
      Manager of Managers will be the first candidates to connect to the Enterprise Service Bus.
      Chapter three contains a high level design of ESB based integrations of some example
      systems with the centralized manager of managers using the new architecture.



      1.3 INTENDED AUDIENCE
      The document is intended for any Service Provider Operations Team and OSS Support
      personnel. It is also a valid Architectural approach for large Enterprise environments where
      multiple tools are used to manage complex IT Environments.            The main purpose is to
      establish a common understanding on how to improve the management performance,
      scalability and simplicity.
                                                                      Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                            OSS SOA Architecture and Requirements


                                                                                                                         Wednesday, June 16, 2010




   2 OSS SOA ARCHITECTURE AND REQUIREMENTS
      2.1 INTRODUCTION
      This chapter contains an overview of the SOA based architecture and the building blocks of
      the architecture including functional and non-functional requirements derived from the
      architectural decisions made.


      The principles of SOA, ESB‘s, and Web Services as well as the key technical standards behind
      them will be covered.



      2.2 OVERVIEW OF SERVICE-ORIENTED ARCHITECTURE BASED
          OSS

      Below is a high level overview of the OSS Integration Architecture based on the Service-
      Oriented Architecture (SOA) concept.


                             Portal                 Workflow            Data                   Application
                             Server                  engine           Warehouse                  Server




                                                                                                      Web Services Layer

                                                    Enterprise Service Bus

                                                                                                             Messaging Layer




                                                                                  Manager of                 BSS Systems
                    Vendor            Performance
                                                               Other NMS          Managers                   (CRM, Billing
                   EMS/NMS             Mgmt Tool
                                                                                                              Activation)




      Systems in the OSS area can integrate with each other through the Enterprise Service Bus
      (ESB). The bus enables both message based integration using message brokers and service
      oriented integration using Web Services. Both concepts are explained in more detail in this
      chapter. The architecture can be extended beyond OSS to interface with BSS systems and
      Service Management applications.
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                         OSS SOA Architecture and Requirements


                                                                                               Wednesday, June 16, 2010




      From physical systems perspective the architecture could look like:



                                    Other NMS
                    Workflow                          Data
                     engine                         Warehouse



          Portal                                                  Application
          Server                                                    Server

                                       ESB
                                     Platform

                                                                   Trouble
        CMIP NMS
                                                                   Ticketing




                                                     Manager of
                   SNMP NMS
                                                     Managers
                                   Syslog NMS




      The ESB platform can be installed on one or more servers. For failover and performance
      requirements it could be necessary to implement the Enterprise Service Bus on multiple
      servers. These aspects should be taken into consideration when defining the requirements in
      the design and selection processes.


      The integration architecture provides the following main functions:
               enabling integration based on standards
               enabling service oriented and message oriented integrations and process automation
               loosely coupling of integrations in order to implement flexibility and enable cost-
                effective implementation of changes, this is explained in more detail in paragraph 2.4


      Below is a more detailed overview how systems are integrated within the OSS SOA based
      architecture.
                                                              Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                   OSS SOA Architecture and Requirements


                                                                                                         Wednesday, June 16, 2010




                                                                                            Web Services Layer

                                                Enterprise Service Bus

                     Broker                                         Broker                     Messaging Layer



                                       SOAP                                       SOAP
                      JMS                                            JMS


                                      Web                                         Web
                   Messaging                                      Messaging
                                    services                                    services
                    interface                                      interface
                                    interface                                   interface


                          Integration Logic                           Integration Logic

                                      JCA                                         JCA
                                    Connector                                   Connector




                             System A                                    System B




      All systems in the OSS area are connected together by the Enterprise Service Bus. The actual
      integration with the system is adapter based and interface-oriented.
      A JCA compliant connector is used to establish a connection with the system. Integration
      logic is used to convert data formats and transform data into a common information
      standard. Only ―common‖ information is exchanged on the Service Bus.
      All integrations with a system in the OSS area will have two interfaces towards the Enterprise
      Service Bus. The first one is a JMS based messaging interface. Information can be sent to
      and from the Service Bus using messages. XML will be used for the payload (content) inside
      the messages. The other interface is based on Web Services.
      WSDL is used to describe the Web Services interface and SOAP messages are used to invoke
      services and exchange data with the services. XML is also used inside the SOAP messages.
      More detailed information about the concepts and technology used will be supplied in the
      next paragraphs.

      2.3 CONCEPTUAL PERSPECTIVE
      The Architecture is based on the following concepts:
               OSS Business and Process Frameworks
               TMF‘s NGOSS concepts
               Enterprise Service Bus (ESB)
               Service Oriented Architecture (SOA)
               Message based integration
               Distributed Application Oriented Integration
               Process Integration
               Human Interaction Integration
                                                             Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                          OSS SOA Architecture and Requirements


                                                                                                Wednesday, June 16, 2010



      Each of these concepts is explained in more detail in the following paragraphs.



      2.3.1 OSS BUSINESS AND PROCESS FRAMEWORKS
      TMN Pyramid
      The OSS area is complex. ITU-T had developed a model to categorize this in management
      layers, the TMN (Telecommunications Management Network) model M.3100.




      Below is an overview of all the layers in OSS area according to the TMNS Pyramid. Please
      note that each layer is dependent on the services provided by the adjacent layer below:


      Layers              Description
      Business            Manages the business processes such as Marketing Plans and Programs,
      Management          Customer Relationship     Management and Resolution, Planning and
                          Strategy, Decision Support and Business process workflow management.
      Service             The telecommunications network provides services to customers. A leased
      Management          line subscription, an email account and a telephone subscription are a few
                          examples. The Service management layer is concerned with management of
                          those aspects that may directly be observed by the users of the
                          telecommunication network.
      Network             When multiple network elements are interconnected they form a network.
      Management          An end-to-end connection or a telephone call uses a set of network
                          resources. The Network Management layer refers to the functionality
                          required to control the network.
      Element             The management functionality that is required to operate a single piece of
      Management          equipment.
      Network             Networking equipment; the single boxes, servers, etc. that constitute a
      Elements            single resource.
                                                            Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                            OSS SOA Architecture and Requirements


                                                                                                  Wednesday, June 16, 2010



      The strength of the TMN model is that it provides the capability to reach a level of abstraction
      which increases through the layers. Ideally there is no need for interference between layers
      that are not adjacent.


      FCAPS model
      Another contribution from the TMN model is the division of management functionality into a
      number of functional areas, the FCAPS model:


      Functional area                    Description
      Fault Management                   Handling of alarms and events.


      Configuration Management           Installing and configuring the object in questions, be it a
                                         service or a physical port.


      Accounting Management              The creation and mediation of resource usage data and the
                                         subsequent rating and billing of the service usage.


      Performance Management             The creation, collection and aggregation of statistics related
                                         to resource usage. The creation and handling of reports
                                         related to the collected statistics.


      Security Management                All   aspects   related   to   security   of   the    management
                                         functionality. The area spans from authentication of the
                                         Operator to access control, i.e. who is allowed to do what,
                                         when, from where.




      The building blocks in the TMN framework can be used to determine integration approaches
      in the OSS area. For example:
               TMN requires that when integrating with a building block, it must contain functions
                from only a single TMN layer and from a single TMN management functional area.
                Integrations inside this building block are built using interface oriented architectures.
               A set of functions grouped into a building block should exhibit loose coupling with
                functions outside the set and high cohesion with functions inside the set. Integrations
                between multiple blocks MUST be decoupled using a messaging backbone in addition
                of decoupling integrations between multiple systems using the message bus.
               Automated processes that span multiple functional building blocks can be built using
                Web Services to invoke functional determined service interfaces.
               The framework can also be used to appoint IT projects related to a functional
                building block. For example the high level design of the ESB based integrations with
                                                         Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                       OSS SOA Architecture and Requirements


                                                                                             Wednesday, June 16, 2010



                the Manager of Manager can be organized as a project to implement changes in the
                functional building block ―Fault Management – Network Management Layer‖.


      To summarize; having a solid OSS framework on business and business process level is a
      very essential part in a successful implementation of an improved integrated OSS
      environment.


      TMF eTOM Process Map
      The TMF process framework TMF GB921 v5.0 or eTOM (Enhanced Telecom Operations Map)
      Model aims to capture and understand all the key business activities of an operator. An
      operator needs to make sure it‘s processes are as normalized as possible to truly take fullest
      advantage of commercial off the shelf technology and to benefit from Industry best practices.
      The eTOM Framework was developed using the combined experience of some of the world‘s
      leading operators and provides a comprehensive reference framework. eTOM is not
      necessarily better than any operators own process definitions, but there is significant value in
      defining a common language for comparing operators and their sub-processes and systems
      for gap analysis. It also facilitates detailed discussions between operators and vendors
      providing an external neutral point of resolution of process differences.
      The purpose of the eTOM Framework is to (continue to) set a vision for the telco industry to
      compete successfully through the implementation of business process driven approaches to
      managing the enterprise. This includes integration of vital enterprise support systems
      concerned with service delivery and support.
      Some of the key elements of the eTOM Business Process Framework will be addressed.




      The figure above, the eTOM Business Process Framework – Level 0 Processes, gives the
      highest conceptual view of eTOM. It provides an overall context that differentiates strategy
      and lifecycle processes from operational processes. It also differentiates the key functional
                                                         Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                      OSS SOA Architecture and Requirements


                                                                                            Wednesday, June 16, 2010



      areas as horizontal layers across these process areas. This view also includes external and
      internal entities that interact with the enterprise (suppliers, partners, shareholders,
      employees).




      The second figure illustrates the Level 1 Processes. This abstraction maps the Layer 0
      processes against the end-to-end operator business processes required to support customers.
      This matrix like view provides the enterprise-level process framework for service providers. It
      provides a standard language and structure for process elements. Further decomposition of
      processes (such as the example below, detailing Operations) is called Level 2. This
      decomposition maps common business processes like Order Handeling, Activation and Billing.
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                       OSS SOA Architecture and Requirements


                                                                                             Wednesday, June 16, 2010




      2.3.2 TMF NGOSS CONCEPTS
      The core aims behind NGOSS is to allow simplified process automation for business coupled
      with improved flexibility and agility. These objectives link to the Lean Operator Program
      objectives:
               To transform operating costs
               To transform business agility
               To transform levels of customer service
               To transform innovation levels


      How this architecture relates to NGOSS
      The architecture, as specified in this document, is based around the principles of the current
      NGOSS concepts. The NGOSS aims at a future state of the OSS IT infrastructure that, in our
      opinion, can be reached only using an incremental approach.


      Operators can first start to implement an Enterprise Service Bus as a central integration
      backbone where all systems in the OSS area connect to. At that stage a message based
      integration backbone from where operators can move to the next stages is established,
      implementing an enterprise wide Common Information Model and digital processes on top of
      the integration backbone.


      These next stages can be built against current NGOSS. It‘s wise to assess improvements and
      technology specific implementations of the NGOSS concepts before determining next steps as
      it is a living program of work and there are regular updates and progress.
                                                         Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                       OSS SOA Architecture and Requirements


                                                                                             Wednesday, June 16, 2010



      Major principles behind the NGOSS Architecture
      When creating this architecture the most important NGOSS principles which were considered
      were as follows:
               inherently distributed
               uses interfaces to communicate
               componentized
               business processes are separated from component implementation
               security-enabled
               may be policy-enabled
               uses shared information and data
               uses a common repository

      Most of these principles are used directly in the OSS integration architecture.


      Common Communication Mechanism
      An NGOSS system must be characterized by the existence of a communication mechanism
      (e.g., a messaging bus) or some other form of common communication. All software entities
      will use one or more communication mechanisms to communicate with each other. Each
      communication mechanism offers one or more different transport mechanisms. There may be
      more than one such communication mechanism within a given system implementation, and
      these mechanisms may represent different technology-specific mappings. The common
      communication mechanism must provide transport mechanisms consistent with the basic
      interaction styles defined in the architecture and any security policies that a service provider
      has defined for his/her network.


      More importantly, the use of a common communications mechanism enables the
      standardization of system-wide operations, messages, or events that can be distributed to
      interested components. This is an important point, as a transport ―just‖ carries information,
      and by itself doesn‘t provide interoperability.



      2.4 SERVICE ORIENTED ARCHITECTURE
      Service Oriented Architecture (SOA) is the approach of defining an integration architecture
      based on the concept of a service. The business and infrastructure functions that are required
      to make an effective ―on demand‖ environment are provided as services. These services are
      the building blocks of the system.
      Services can be invoked independently by either external or internal service requesters to
      process simple functions, or can work together in choreographic implementations to quickly
      devise new functionality for existing processes.
      SOAs may use Web Services as a set of flexible and interoperable standards for distributed
      systems. SOA and Web Services complement each other as described later.
                                                           Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                        OSS SOA Architecture and Requirements


                                                                                              Wednesday, June 16, 2010


      2.4.1 THE FOUR KEY TECHNOLOGY ELEMENTS




      SOA touches on the four key elements of on demand e-business in the following way:


      Open standards
               SOA provides a standard method of invoking Web services (business logic and
                functionality) for disparate organizations to share across network boundaries.
               Web services use open standards to allow inter-enterprise connectivity across
                networks and the Internet:
                     o    Messaging protocols (SOAP).
                     o    Transport protocols (including HTTP, HTTPS, JMS).
                     o    Security can be handled at both the transport level (HTTPS) and/or at a
                          protocol level (WS-Security).
               WSDL allows Web services to be self-describing for a loosely coupled architecture.
                Standards bodies, including WS-I, W3C and OASIS exist using technologists from
                industry leading software vendors (IBM, BEA, Oracle, Microsoft and so forth) to
                accelerate and guide open standards creation and adoption.
      Integration
               Interfaces are defined in such a way to wrap service endpoints providing a system-
                independent architecture that promotes cross-industry communication.
               SOAs can provide dynamic service discovery and binding, which means that service
                integration can occur on demand.
      Virtualization
               A key principle of SOA is that services should be invoked by service requesters that
                are oblivious to service implementation details, including location, platform, and if
                appropriate to the business scenario, even the identity of the service provider.
               Grid services and the very framework it all rests on is very much like object-oriented
                programming.
      Automation
               Grid technologies are applying SOA principles to implementing infrastructure services
                that will provide an evolutionary approach to increased automation.
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                       OSS SOA Architecture and Requirements


                                                                                             Wednesday, June 16, 2010




      2.5 ENTERPRISE SERVICE BUS (ESB)
      The Enterprise Service Bus (ESB) is to SOA as SOA is to business agility. This chapter
      describes the way that the ESB can help businesses create processes that meet the objectives
      of the capabilities of an agile environment.


      In order to create a truly successful on demand e-business, one must embrace the SOA
      which helps businesses wrap functions (services) to provide loosely coupled accessibility to
      functions, flows, and applications.




      The three core components of the ―on demand‖ OSS Environment, namely integration
      services, Enterprise Service Bus, and infrastructure services, work together to provide the
      capability to meet defined business objectives.
      Business services leverage the application and infrastructure services, which are mediated by
      the Enterprise Service Bus, to provide real business processes to end users including
      customers, employees, and business partners.
      Business service management incorporates the policies and goals of the organization, such as
      service levels, metrics, and other measurable business guidelines.



      2.5.1 ENTERPRISE SERVICE BUS
      The Enterprise Service Bus is emerging as a service-oriented infrastructure component that
      makes large-scale implementation of the SOA principles manageable in a heterogeneous
      world.


      On demand applications are business services built from services that provide a set of
      capabilities worth advertising for use by other services. Typically, a business service relies on
                                                           Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                        OSS SOA Architecture and Requirements


                                                                                              Wednesday, June 16, 2010



      many other services in its implementation. Services interact via the Enterprise Service Bus,
      which facilitates mediated interactions between service endpoints. The Enterprise Service Bus
      supports event-based interactions as well as message exchange for service request handling.
      One innovation of the Enterprise Service Bus is a common model for messages and events.
      All messages can become events if deploying the service binds the message to a topic in the
      event space.


      For both events and messages, mediations can be used to facilitate interactions (for example,
      to find services that provide capabilities that a requestor is asking for or to take care of
      interface mismatches between requesters and providers that are compatible in terms of their
      capabilities). In this context, we use the term service in a very general sense, and it might be
      worth noting that although from the perspective of the bus all application components can be
      specified through WS-* standards (because it requires a normalized representation for
      efficient mediated, capability-based matchmaking), this does not imply that they all
      communicate with SOAP or WS-* protocol standards. The Enterprise Service Bus supports a
      broad spectrum of ways to get on and off the bus, including on ramps for legacy applications
      or business connections that enable external partners in B2B interaction scenarios to
      participate in the service interaction game.


      Although they all look the same from the perspective of the Enterprise Service Bus, services
      implement different facets of an overall on demand application, including:
               Realize interactions with people involved in the underlying business process.
               Provide adapters to existing applications that need to be integrated.
               Choreograph the interaction of several services to achieve a business goal.
               Watch for potential problems in the execution of the process, ready to take action to
                fix them if they occur.
               Manage resources that are needed to perform required business functions.


      Therefore, in addition to providing the basic infrastructure for service interactions, the on
      demand Operating Environment identifies a set of common patterns for construction of on
      demand applications and provides specific capabilities to support realization of distinct service
      categories that play particular roles in those patterns. The two distinct service categories are
      integration and infrastructure service kinds.



      2.5.2 INTEGRATION SERVICES
      The programming model for on demand business services is based on application
      development using component (service) assembly. The services in the integration category
      are used by on demand application builders to create new business services; they include
      services that facilitate integration as well as services that provide business functions to be
      integrated:
      User access services
               Handle adaptation from three orthogonal perspectives:
                                                           Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                         OSS SOA Architecture and Requirements


                                                                                               Wednesday, June 16, 2010



               Endpoint form factor such as display size, memory, and processor limitations (ranging
                from desktop down to pervasive devices)
               Modes of interaction including conventional display/keyboard interactions, as well as
                speech-based interactions and combinations (multi-modality)
               Connection types such as peer-to-peer or client/server across a range of connection
                reliability including fully disconnected operations
      User interaction services
               Handle direct interactions with people involved in the business process; for example,
                processing work items that are spawned by choreography or collaborative process
                elements.
      Business process choreography services
               Support the execution of other services that express their behavior using process
                flow or rule technology. Process flows, for example, are used to describe the
                interaction of other services (nearly any of the integration kinds, including other
                process flow services) to perform the tasks required to realize the functions offered
                by the new (combined or aggregated) business service.
      Business function services
               Provide the atomic business functions (those that are not composed from other
                services) that are required by the overall business service; this includes adapters to
                packaged or existing custom applications as well as brand new application
                components created to realize a functional need that is not already covered by
                existing applications.
      Common services
               Implement useful features, or helper functions, that are designed to be used by
                many business services. Examples include services implementing personalization of
                user access and user interaction services, or for reporting status and progress of
                business services.
      Information management services
               Help to integrate information hosted in a variety of data sources such as databases
                or legacy applications, to access (query, update, and search) that information, to
                analyze information from those sources in business intelligence scenarios, or taking
                care of metadata about information and services used and provided by the business
                services living in the on demand Operating Environment.



      2.5.3 INFRASTRUCTURE SERVICES
      The services in the infrastructure category provide and manage the infrastructure into which
      business services and their constituents are deployed. These include:


      Utility business services
               Support functions such as billing, metering, rating, peering, and settlement;
                commonly used, for example, when hosting on demand business services or their
                components.
      Service level automation and orchestration
                                                           Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                        OSS SOA Architecture and Requirements


                                                                                              Wednesday, June 16, 2010



               Provide services that facilitate translation into reality of quality of service policy
                declarations that are associated with business services. This is achieved by services
                that implement autonomic managers, which monitor the execution of services (more
                precisely, services instrumented to be managed elements) in the on demand
                Operating Environment according to the policy declarations they receive. They then
                analyze their behavior, and if the analysis indicates problems, plan a meaningful
                reaction to that problem and initiate execution of that plan. This closed feedback loop
                is called an M-A-P-E (Monitor, Analyze, Plan, Execute) loop. Several specializations of
                such services focus on managing, for example, availability, configuration or workload
                for the managed elements, provisioning resources, performing problem management,
                handling end-to-end security for on demand Operating Environment services, or
                managing data placement.
      Resource virtualization services
               Provide the instrumentation of server-, storage-, network-, and other resources,
                including structured (relational) and unstructured information content that is held in a
                variety of data sources, to enable management and virtualization of those resources
                under the control of on demand Operating Environment resource managers.
                Virtualization services include mapping requirements of business services and their
                components to available resources based on quality of service declarations of the
                service and knowledge about the current utilization of available resources.


      Messaging backbone
      One of the key aspects of the Enterprise Service Bus is the messaging backbone. This
      concept of a message bus supporting the exchange of messages between systems attaching
      to the bus has been introduced. This significantly reduces the number of integrations by
      decoupling systems, since the system only integrates with the bus itself.


      The main functionality of the message bus is:
               Deliver support for a distributed environment. A software component could be
                located anywhere.
               Guaranteed message delivery. If a certain system is temporarily down, the bus will
                deliver the message when it comes back up again.
               Implementing different messaging models. The two most obvious are request – reply
                (traditional client - server), and publish – subscribe type of operations.
               Furthermore additional functionality for security, transactions support, etc. may be
                included.


      The message bus involves more then just transport of messages. It is equally important to
      standardize the content, structure and format of messages that are to be exchanged.
      This can be accomplished to some extent by using ―self-describing‖ data. XML is the
      dominant standard for realizing this. However, the prevailing method is to go further and
      agree on a common information model, at least for the information objects that need to be
      exchanged. The so called ―Common Business Object Model‖ is achieved by converting a
      native message to the common information model when a message is sent to or published on
                                                         Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                      OSS SOA Architecture and Requirements


                                                                                            Wednesday, June 16, 2010



      the bus. The conversion of a message can be performed in the adapter based integration
      before it is exchanged on the message bus.



      2.6 DISTRIBUTED INTERFACE ORIENTED ARCHITECTURE
      The basic architecture underlying NGOSS is that of a Distributed Interface-Oriented
      Architecture (DIOA). This architecture distinguishes objects as ―building blocks‖.


      The ―building block‖ is a deployable unit of interoperating software. There is a need for a
      deployment entity of larger granularity than the programming objects, some kind of holder or
      container for them, and a standard means for the objects to deal with the outside world via
      this container.


      Building blocks are smaller units of software than the server-side applications commonly
      deployed in the past. No single building block can solve a business problem by itself. Sets of
      building blocks must collaborate in logical systems, connected together by an Enterprise
      Service Bus.


      Several of these DIOA‘s have been defined in IT industry like CORBA and Java RMI. NGOSS is
      an OSS-specific profile of the concepts defined in many of these DIOA‘s. The J2EE
      environment supports the concepts of NGOSS in this area.


      The ability to integrate components and to develop a market of components depends
      fundamentally on the notion of component interface. An interface is a coherent set of
      functional capabilities (both attributes and operations) of a component that users/clients of
      those capabilities can rely on. The Java based OSS/J initiative focuses on delivery of
      standardized interfaces to integrate with systems in the OSS area and now forms part of the
      TMF efforts. The interfaces are a technology specific implementation of the NGOSS
      standards.



      2.7 PROCESS INTEGRATION
      NGOSS provides a path toward improved business process automation through the
      integration and interoperation of commercial off the shelf software. Web Services, as part of
      the ESB concept, can be used as building blocks for automating internal and external
      processes on services level.


      Building blocks for process integration contain functionality that implements process business
      rules derived from an enterprise business process model.


      Some examples of necessary functionality are:
                                                           Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                        OSS SOA Architecture and Requirements


                                                                                              Wednesday, June 16, 2010



               Control of process flows,
               Coordination of multiple related user tasks,
               Activity control,
               Complex retrievals, or access to multiple objects encapsulated in a number of
                building blocks,
               Operations that are long-running, or background, or batch oriented.


      TMF provides the Enhanced Telecom Operations Map (eTOM). This map provides a Business
      Process Framework in which the automated processes can be implemented.



      2.8 HUMAN INTERACTION INTEGRATION
      Human Interaction Integration is concerned with issues related to human/computer
      interaction. Integrating the human interaction involves these main areas:
               User Interface (UI): structures the presentation to the user and makes the functional
                features of the building block available to the user. The ESB based architecture can
                expose business functions inside the OSS area as Web Services.
               Task Manager & Workflow: encapsulates an understanding of the user‘s goals and
                tasks and contains the functions needed to accomplish the automated portions of the
                user‘s job; executes process business rules requiring human interaction and control.
                Most workflow engines on the market today are based on a messaging backbone to
                exchange workflow and workflow relevant/ task data. The ESB based architecture
                supports such a backbone and also offers a Web Services layer to facilitate data
                exchange resulting from human interaction
               Security Manager: identifies and authenticates the user and determines the user‘s
                level of authorization to access the functions of the building block. The Enterprise
                Service Bus can be used to implement standard security features and integration with
                existing directory servers like LDAP and IdM solutions.
               Portal: latest portal technology can build a loosely coupled display interface layer on
                top of business functions exposed as Web Services. New Composite applications can
                be created by using exposed services to enable new portal based applications for
                consumption.
               Dashboard: structures the presentation of selected KPI‘s to subscribed internal users
                to provide a real time view of events. The ESB based architecture can expose events
                in a dashboard application or ticker. Events can also be published to an SMS
                notification platform to alert (internal) stakeholders or published to the customer care
                platform to be processed to create notifications on IVR systems.
               Selfcare: Allowing Users to use a series of online tools to manage their own service
                without the need of speaking to a company call centre employee. Selfcare tools can
                include billing queries, testing of customer connection, purchase of services and other
                user instigated requests .


      All integrations regarding human interaction should be loosely coupled with the process
      integration and enterprise application integration. This also offers flexibility to implement
      different technologies in the different areas. The ESB based architecture is based on the
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                       OSS SOA Architecture and Requirements


                                                                                             Wednesday, June 16, 2010



      assumption that the Web Services interfaces and messaging backbone provide enough
      functionality to build the appropriate solutions for human interaction in a portal or application
      server environment.



      2.9 TECHNOLOGY PERSPECTIVE
      The SOA Architecture is based on the following standards:
               Web Services (HTTP, SOAP, WSDL and XML)
               JCA
               JMS
      Each of these concepts is explained in more detail in the following paragraphs.



      2.9.1 WEB SERVICES
      There is no universally accepted definition of ―Web Services‖. Gartner Group defines Web
      Services as: ―Loosely coupled software components that interact with one another
      dynamically via standard Internet technologies.‖ In contrast, Forrester Research defines Web
      services somewhat abstractly as: ―Automated connections between people, systems and
      applications that expose elements of business functionality as a software service and create
      new business value.‖


      Web Services are building blocks for creating open distributed systems. A Web Service is a
      collection of functions that are packaged as a single unit and published to the network for use
      by other software programs. Web Services can aggregate other Web Services to provide
      higher-level functionality, for instance, a complete order management service, in true
      business process collaboration.


      Web Services has the following characteristics:
               Cross-platform and language independent integration,
               Loosely coupled and Interchangeable,
               Based on open internet protocols, formats and interfaces,
               Building blocks that can form more complex services.


      From a technology point of view, Web Services is about connecting disparate software
      systems using a set of standard protocols in a way that enables seamless information and
      process flow among the different systems.


      Web Services define four logical protocol layers to achieve this seamless integration:
      Transport, Messaging, Data Definition, and Process Definition. The table below shows how
      these layers map to the specifications usually associated with Web Services.
                                                             Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                          OSS SOA Architecture and Requirements


                                                                                                Wednesday, June 16, 2010




      Web Services Layer                            Applicable Standards that are emerging
      Process         Definition      (document,    BPML (Business Process Markup Language) and
      workflow, transactions, process flow)         BPEL4WS (Business Process Execution Language
                                                    for Web Services) can be used to create flexible
                                                    automated business processes.
      Service Definition (encoding and type         WSDL (Web Services Description Language) is an
      schema definitions)                           XML format for defining interface and connection.
      Information         Messaging    (message     SOAP (Simple Object Access Protocol) is an XML
      packaging,          routing,    guaranteed    messaging standard for information exchange in an
      delivery, security)                           open network environment.
      Transport (message transport)                 HTTP     (Hypertext   Transport    Protocol)   is   the
                                                    transport protocol for the Web and one of several
                                                    transports that Web services can use.


      In addition to SOAP and WSDL, the Universal Description, Discovery, and Integration
      specification (UDDI) is often considered a component of Web Services. However, UDDI,
      which defines a protocol for publishing and discovering information about business ser-vices,
      is not a required element for implementing Web Services architecture.


      Below is an overview of the core Web Services:




      Operators needs to select a vendor for the ESB solution that offers extensive Web Services
      support. In additional to the technical reasons, we‘ve specified some business drivers for
      using Web Services:
               Replace tightly coupled architectures with a plug and play architecture,
               Handle inflexible, static application interfaces,
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                       OSS SOA Architecture and Requirements


                                                                                             Wednesday, June 16, 2010



               Rapidly and inexpensively provide connections between existing systems and
                partners,
               Expose business functionality as a set of standard, reusable processes.



      2.9.2 JCA BASED INTEGRATIONS
      The J2EE Connector Architecture (JCA) provides application integration technology with the
      standardized method for integrating non-J2EE back office systems. JCA is also referred to as
      Enterprise Information Systems (EIS) with J2EE components, using a common API and a
      common set of services that developers can employ.


      JCA defines a standard architecture and adapter behavior (J2EE Connector Architecture 1.5 ).
      This standard gives the ability to create an adapter once, and then use it anywhere, including
      most integration and application servers. This provides many advantages.


      Adapters deal with the low-level details of the underlying application, database, and
      standards-based (EDI, XML, etc.) interfaces. These adapters are available on the market for
      most standard systems for other systems it is possible to build custom adapters.


      Adapters are used to:
               Create common interfaces into source or target systems that provide a consistent set
                of services,
               Create reusable set of software services that can extract and publish information to
                source or target systems, which removes the need to build an interface for each
                individual integration.


      Below is an overview of a basic JCA Architecture. The implementation of the JCA Architecture
      can differ between vendors. Most vendors extend the JCA standard to implement more
      functionality.
                                                         Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                      OSS SOA Architecture and Requirements


                                                                                            Wednesday, June 16, 2010



           J2EE Application Server         Container-Component
                                                 Contract         J2EE Application
                                                                    Component
       Connection
       Manager
                                                                           Common Client Interface
                      Transaction
                      Manager
                                             System Contracts
                                                                 Resource Adapter
                                Security
                                Manager




                                                                           EIS-Specific Interface


                                                                      Enterprise
                                                                 Information System




      2.9.3 JMS BASED MESSAGING
      Java Messaging Service (JMS) adds a common API and provider framework to Java, which
      enables the developers to dispatch and receive messages with other Java-enabled
      applications that exist anywhere on the network. JMS defines a common set of messaging
      concepts and programming strategies.


      JMS consists of three major entities: the JMS provider, JMS messages, and JMS domains. The
      JMS provider implements JMS for a particular product. This is also true for ESB vendors that
      implement JMS as interface to communicate with their message broker.


      Be aware that JMS implementations by JMS-compliant vendors can differ. Most differences
      result in the need for bridges in order to exchange messages between the two products.



      2.10 LOOSE COUPLING FOR FLEXIBILITY
      Loosely coupled integration is the main essence of the OSS integration architecture.
      It maximizes interoperability, flexibility and cost effective changes on individual components
      in addition to the other objectives of the architecture. Loosely coupled integration can be
      realized on both functional and IT level.
      Related to loosely coupled integration is the concept of ―Separation of concerns‖. This is a
      concept in software architecture which promotes ease of development, ease of maintenance,
      and increased reliability by means of functional separations within and between systems.
                                                           Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                        OSS SOA Architecture and Requirements


                                                                                              Wednesday, June 16, 2010



      Below is an overview how separation of concerns in the OSS integration architecture is
      realized using the following loosely coupled integration concepts, mostly derived from the
      NGOSS initiative.


               Isolation of business processes from enterprise data: By keeping enterprise data in
                one place, different building blocks representing parts of different business processes
                have uniformity of access to the same copy. This alleviates the problem of multiple
                copies loosing synchronization, promoting enterprise data integrity.
               Isolation of Business Processes and Enterprise Data from Display Characteristics: The
                manner in which building blocks interact with one another should not be constrained
                by the characteristics of display devices.
               Isolation of Business Processes and Enterprise Data from Human Interaction: The
                manner in which building blocks interact with one another should not be forced to
                model human interactions, nor should a human be forced to act like a computer in
                order to use one.
               Separation of Business Processes from Component Implementation. A NGOSS system
                must be characterized by the separation of the hard coded behavior of components
                from the software that automates business processes. The business process should
                be composed of defined services that can be orchestrated using scripting/process
                management technologies based on Web Services
               Decoupling of Technologies: The three tiers: human interaction integration, process
                automation and enterprise application integration are decoupled and tend to utilize
                different technologies. A messaging backbone and Web Services are key concepts
                inside the integration architecture to loosely couple tasks inside processes, to
                separate integration logic from the process and to separate human interaction logic
                from the business functions.
               Usage of informational standards or a so called ―Common Business Object Model‖ is
                achieved by converting a native message to the common information model when a
                message is sent to or published on the message bus. The conversion of a message
                can be performed in the adapter based integration before it is exchanged on the
                message bus. An example for this could be the usage of a standardized ―alarm/
                event‖ message on the message bus. In this way the consumer (Manager of
                Managers) isn‘t aware of the custom formats that existed before information was
                released on the message bus.
               Implementing the asynchronous publish-subscribe messaging model on the message
                bus increases scalability and enables really loosely coupled integrations between
                systems. The systems as producer of information aren‘t ―aware‖ of the consumers of
                the data.
               Usage of XML as technology for communication and information standard. One of the
                attractions of XML from an NGOSS perspective is its ability to allow communicating
                software system to be loosely coupled, both in their technology bindings (XML is
                protocol and programming language independent) and their binding to common
                models (well formed XML information can be processed without prior knowledge of
                its full schema).
                                                              Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                   SOA based Architecture with Manager of Managers


                                                                                                   Wednesday, June 16, 2010




   3 SOA BASED ARCHITECTURE WITH MANAGER OF
     MANAGERS
      3.1 INTRODUCTION
      This section gives a high level description of the integration of some OSS Systems with the
      Manager of Managers based on the SOA architecture.
      The integrations described in this chapter will focus on retrieving fault management data
      (events) from example network management systems. The data will be transformed and
      made available as messages in a canonical format on the ESB. A manager of manager‘s will
      pick up the messages and process them accordingly. The following network management
      systems have been chosen as an example to illustrate the principle:
               C-COR CableEdge
               Nortel Preside for Optical Networks
               HP Openview TeMIP
      In this example CA Spectrum will act as the manager of managers. It is used to provide a
      consolidated monitoring environment for one NOC. It should be noted that there a several
      platforms available in the market place that perform this function, Spectrum is used in this
      example to illustrate the concept.


      It is necessary to determine how each system can be connected to an Enterprise Service Bus.
      The integrations will be high level designs based on the following principles:
               When possible a JCA 1.0 compliant connector will be used to build the integrations
                with the systems in the OSS environment. If such connector is not available, custom
                solutions should be used to integrate, for instance: JDBC, direct API-calls, SNMP, etc.
               The ESB environment will perform transformation and transportation services.
               All systems are integrated through the Enterprise Service Bus.



      3.2 HIGH LEVEL INTEGRATION DESIGN
      The concept of the four management systems connecting to the service bus is illustrated in
      the figure below.



                                                                                      Web Services Layer

                                              Enterprise Service Bus

                                                                                         Messaging Layer




                     Nortel                            C-COR
                                   HP TeMIP                            CA Spectrum
                    Preside                           CableEdge
                                                        Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                            SOA based Architecture with Manager of Managers


                                                                                            Wednesday, June 16, 2010




      Every system has its own format and data structure that will be transformed into an
      appropriate ―common‖ format (canonical).


      Using this approach one can standardize both on technology and information standards in the
      SOA based architecture. Future integrations must adopt the standards set by this architecture
      and can then also be integrated on a cost-effective way.


      Different systems can have different integration gateways. Some specific integrations with
      the individual systems are further addressed in the next paragraphs. There are some
      common aspects which will be discussed first.



      3.2.1 CORBA INTEGRATION INTERFACES
      A number of network management systems have a CORBA-gateway. For CORBA gateways
      there are several solutions. There are JCA connectors that support CORBA. There are also
      solutions that encapsulate a CORBA-interface to a web service.


      An important aspect to consider with CORBA and JCA-connectors that JCA 1.0 doesn‘t
      support asynchronous messaging. This implies that the connector has to poll the monitored
      system. An advantage of polling is that sometimes faults don‘t appear on the monitor
      because they are solved within the polling time. A disadvantage is that the alarm can come
      after a customer reports an incident. For the synchronous interfaces a connector can be
      used.



      3.2.2 SNMP INTEGRATION INTERFACES
      For applications that produce SNMP traps it is feasible to catch those using a simple SNMP
      message listener. This piece of custom code can filter a message, transform it to a ―common‖
      XML format and send it as a message to the Enterprise Service Bus. A big advantage of this
      approach is that it is not intrusive: the messages are produced anyway.



      3.2.3 DATABASE INTEGRATION INTERFACES
      Some systems do not offer a suitable integration interface to call system functions and
      exchange data. Often such systems have an open database, making it possible to integrate
      directly through JDBC. This Java based database connectivity standard is supported in most
      ESB environments. Advantage of using JDBC is that the integrations are standardized
      independent of the database system that supplies the JDBC interface.
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                              SOA based Architecture with Manager of Managers


                                                                                              Wednesday, June 16, 2010



      3.3 MANAGER OF MANAGERS INTEGRATION
      Most manager of managers applications support a vast range of applications and devices, so
      called management modules. The Network management systems are to be integrated with
      the Enterprise Service Bus in order to send ―common‖ event messages. Spectrum will
      subscribe to ―common‖ event messages through its South Bound Gateway.



      3.3.1 INTEGRATION TOUCH POINTS
      There are three ways to map events using the Southbound Gateway: SNMP-traps, XML
      import or CORBA.
      The illustrated solution is based on using the XML interface, considering the good fit with the
      Enterprise Service Bus based architecture in which XML plays an important role.



      3.3.2 INTEGRATION BASED ON SOUTHBOUND XML INTERFACE
      All incoming XML documents have to comply with the document type definition
      (sbgwimport.dtd) for event data. Below is a sample XML-file containing two events:
      <?xml version="1.0" standalone="no"?>

      <!DOCTYPE Import SYSTEM "sbgwimport.dtd">

      <Import>

          <Event eventType="0x3e50001"

                  uniqueId1="test_model 1"

                  uniqueId4="xxxx4"

                  uniqueId2="yyyy2"

                  uniqueId3="zzzz3"

                  eventModelName="test_event_model 1"

                  modelClass="Router"

                  eventTimeStamp="current"

                  networkAddress="10.253.9.17"

                  userDefined_101="Device port 1 down"

                  userDefined_102="Severity: High"

                  userDefined_111="Contact: "/>

          <Event uniqueId1="test_model 2"

                  eventType="3e50001"

                  modelClass="NT"

                  networkAddress="10.112.30.7"

                  macAddress="00.04.27.0c.52.03"

                  userDefined_101="Contact Lost"

                  userDefined_102="Severity: Low"

                  userDefined_105="Cause: power down"/>
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                              SOA based Architecture with Manager of Managers


                                                                                              Wednesday, June 16, 2010



      </Import>



      All XML documents have to be sent to Spectrum using the sbgwimport tool. The XML gateway
      does not support the HTTP or FTP protocols. Messages from the Enterprise Service Bus have
      to be saved as physical files on the file system.


      Below is an overview of the syntax that is used:
      sbgwimport –vnm < name of the SPECTRUM server> <filename>



      Spectrum‘s Southbound Gateway checks the IP address of the sending party in order to
      identify the appropriate EventAdmin model.


      The Spectrum integration will subscribe to event messages on the broker. A new message
      will trigger the integration. The XML payload containing events will be extracted from the
      message and saved to the file system. The next step in the process is to activate the
      command line sbgwimport tool or a relevant CORBA function.



      3.4 C-COR CABLE-EDGE INTEGRATION
      C-COR CableEdge is an application that is used to monitor the ‗last mile‘ of cable networks,
      close to the consumer. That implies that a large amount of devices report to the C-COR
      Nodes which then report to the Cable-Edge Controllers. C-COR CableEdge is used for
      configuration, provisioning and fault monitoring.



      3.4.1 INTEGRATION TOUCH POINTS
      C-COR CableEdge is capable of sending e-mails for alerting purposes. An integration solution
      could retrieve these emails from the mailbox they were sent to. Advantage of this solution is
      that it is non intrusive. A disadvantage of this solution is the delay between the moment the
      fault was generated and noticed by the target application.




      3.4.2 INTEGRATION BASED ON E-MAIL NOTIFICATION
                                                                           Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                    SOA based Architecture with Manager of Managers


                                                                                                                    Wednesday, June 16, 2010



           Mail                                 Client Side Process                      MoM Fault
          Server                                                                      Management Side
                                                                                          Process

                                             JCA Mail                            XML Event to
                                  POP3       Adapter                             MoM Service
                                 Message




                                                             Mail to XML
                                                              Service                                         Manager of Manager



                                               XSLT
                                           Transformation


                    SMTP
                   Message
                                                                      ESB Container




                                            MQ Message                           MQ Message




                                                                 MQ
        Management Application




      An integration for systems which use E-mail as a notification method could be built using an
      email client. The mailbox would be polled with a defined time interval. New event data would
      be extracted from the e-mail, transformed to the canonical data format for events, and put in
      a message as XML payload. The message can then be published to the ESB.



      3.5 NORTEL PRESIDE INTEGRATION
      Nortel Preside is an application which monitors Optical SDH and DWDM Nortel devices inside
      the transport network.



      3.5.1 INTEGRATION TOUCH POINTS
      At the time of writing there are two usable gateways: the CORBA interface and the External
      Alarm Interface (EAI).
      CORBA could be used, pulling alarm events from the alarm-log. Advantage would be the
      possibility of a JCA compliant adapter. A disadvantage would be that it is a scheduled pull
      mechanism and as such not real-time.
      The External Alarm Interface pushes all types of messages from all network elements to a
      telnet client. A disadvantage of the EAI would be that it sends more messages then needed,
      but they could be filtered before putting them on the ESB. A clear advantage is that it would
      not need a scheduler.


      The sample solution is based on the Nortel Preside EAI interface. The main reason for this is
      the real-time aspect and avoiding the CORBA-API licensing costs.
                                                                        Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                 SOA based Architecture with Manager of Managers


                                                                                                                 Wednesday, June 16, 2010


      3.5.2 INTEGRATION BASED ON THE EXTERNAL ALARM INTERFACE
      A telnet session to the Preside server will open the External Alarm Interface. After the client
      initiates this session, the EAI starts with a notification of all network elements. Then it will
      send keep-alive messages every minute, accompanied with eventual alarm messages. The
      client will catch these messages, filter them, enrich them using translation tables, format
      them into a XML document, which will be put on the ESB.


                                            Client Side Process                      MoM Fault
                                                                                  Management Side
                                                                                      Process

                                         JCA Telnet                          XML Event to
                              Telnet      Adapter                            MoM Service
                             Session


                                                                                                              JMS
                                                        EMS Telnet to
                                                        XML Service                                       Manager of Manager



                                           XSLT
                                       Transformation

          Telecoms Element
             Management
               System                                             ESB Container




                                        MQ Message                           MQ Message




                                                             MQ




      3.6 TEMIP INTEGRATION
      HP OpenView TeMIP is a very rich tool for monitoring NMS‘s. It enables development of own
      management modules.



      3.6.1 INTEGRATION TOUCH POINTS
      TeMIP has extended at TeMIP 5 the number of northbound gateways. Included are the SNMP
      and XML as well as OSS/J.
      At the time of the development of this specific adapter there are three supported gateways.
      One of them is specific for the Tibco EAI platform and will not be covered here. Furthermore
      there is a CORBA interface and an OSI interface, which is most commonly used interfacing
      protocol in Telecoms for Element to Element Manager communication.
      Here a solution based on the CORBA interface will be covered as it is a dominant technology
      in the Telecom Management / OSS arena and most o the big Telco manufacturers developed
      their OSS platform on CORBA through the late 90‘s- early 00‘s.
                                                                        Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                 SOA based Architecture with Manager of Managers


                                                                                                                 Wednesday, June 16, 2010


      3.6.2 INTEGRATION BASED ON GATEWAY
      A CORBA JCA compliant connector will be used to setup a connection with the TeMIP
      environment. The connector will pull the alarm messages; format them into a XML document,
      which will be sent as message to the Enterprise Service Bus.




                                             Client Side Process                      MoM Fault
                                                                                   Management Side
                                                                                       Process

                                                                             XML Event to
                                        CORBA Request
                              CORBA                                          MoM Service
                             Response


                                                                                                              JMS
                                                         CORBA to XML
                                                           Service                                        Manager of Manager



                                            XSLT
                                        Transformation

          Telecoms Element
             Management
               System                                              ESB Container




                                         MQ Message                          MQ Message




                                                             MQ
                                                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                      OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                                                             Wednesday, June 16, 2010




   4 OSS INTEGRATION ROADMAP – GAINING
     BUSINESS VALUE FROM SOA
      4.1 INTRODUCTION
      This section describes an example roadmap to implement the new IT infrastructure based on
      the OSS SOA Architecture. Depending on the goals there can be several approaches worth
      considering. All approaches will require a SOA Infrastructure.
      The Integration Roadmap is based on a pragmatic program approach consisting of four
      phases. This is no small undertaking and is better broken into smaller more digestable
      projects.
      Each phase will implement an important step of the roadmap by defining the projects that
      need to be executed. Each specified project can be used as a framework to add more tasks
      and determine resources.
      The roadmap consists of a program with four phases:
                    Phase 0 Creation of SOA based integration environment
                    Phase 1 Implement all integrations related to Fault Management and Performance
                     Management
                    Phase 2 Configuration Management and Process Automation based on OSS
                     Integration Platform
                    Phase 3 OSS & BSS integrations and Service Management using the achieved
                     integration results from the previous phases.




                                                                                                                                        Service Management
      Phase 3




                                                                                                                    OSS / BSS Integrations




                                                                                                     Process Automation
      Phase 2




                                                                               Configuration Management



                    SOA Architecture
                                                    Performance Management Integrations
      Phase 1




                                        Fault Management Integrations
      Phase 0




                      SOA ESB Integration Infrastructure
                                                           Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                       OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                     Wednesday, June 16, 2010




      4.2 PHASE 0 – DEPLOYING THE SOA FOUNDATIONS
      We will also cover how to create a business case for SOA Architecture, as it is often a difficult
      thing to show the business benefits long term, and to persuade the first project to deploy any
      associated Integration technology to swallow the costs. SOA as an architectural approach
      requires high level buy in as it requires everyone to be developing using the same methods,
      best practises, Data Model and Naming Conventions to realise the full benefit.


      An initial requirements gathering phase is needed to determine the following:
               Definition of an OSS SOA Architecture
               Definition of SOA requirements based on Architecture
               Identification of systems in OSS area for possible integration
               Analysis of Integration concepts in the market
               High level design of limited number of integrations with the Fault Manager of
                Managers to prove the concepts
               Collect detailed interface information about current systems and messaging formats.




   4.2.1 SET UP OF A COMPETENCE CENTRE
                                                                   Integration Competency Centre (ICC)

                                                                         Organisation & Governance
      In order to best benefit from reuse of services
      deployed within the architecture it is important           Framework
                                                                                                  EDM/CDM
      from the outset to have strong Standards, best                Naming
                                                                                     Patterns
                                                                  Conventions                     Messaging
      practice and methodologies which are consistently
      applied and governed. Governance is one of the             Tools & Components
                                                                                    Exception
      most difficult things to apply to an existing                Monitoring                     Monitoring
                                                                                    handling
      organization as a policing function is often not
      popular. It is important therefore, that one of the         Best Practices

      other roles of the Competency Centre is of                   Business
                                                                                   Architecture    Design
                                                                   Analysis
      internally     marketing   the   benefits   of    SOA
      Integration to gain buy-in from the business.                  Build            Test
                                                                                                  Deploy &
                                                                                                  Configure
                                                            Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                          OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                    Wednesday, June 16, 2010



      During phase 0 the following activities are required:
               Determine analysis & design standards and tools
               Define best practices for integration projects
               Develop change and version control procedures and tools
               Determine coding and naming standards
               Define security implementation standards for different scenarios
      Testing methodology
               Define integration testing approach
               Define user acceptance testing approach
               Define performance & stress testing approach
               Assemble all approaches in overall testing document
               Determine issue management and prioritization procedures
               Define vendor management need during test phases
      Production readiness and migration
               Define deployment and migration approach
               Create templates and readiness checklists
               Define training plans
               Determine reusability and integration component classification
               Create configuration management approach and procedures
      Post-production and support
               Define integration systems management models
               Develop configuration & deployment procedures and best practice
               Determine administration & monitoring frameworks
               Create production support model, requirements and approach
               Define support procedures with Vendor's Technical Support
               Define integration environment tuning considerations
               Develop transition procedures to support team
      ESB Infrastructure
               Selection of vendor for ESB integration software
               Create integration design based on OSS Architecture
               Installation of ESB platform in a development, testing and production environment
               Create installation & Configuration guide
               Development of Manager of Managers integrations
               Perform unit and system testing
               Create deployment guideline and procedures
      Define scope for phase 1
               Define systems and information flows as integration candidates
               Determine integration projects with clear objectives and deliverables
               Determine resources needed


   4.2.2 BUSINESS BENEFITS
                                                                Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                              OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                        Wednesday, June 16, 2010




      Cost of Integration
               Architecture (typically 80% of initial setup)
               Licensing, Creation of Strategy, Initial Setup
               Development
               Capital cost of building integrations
               Operations
               Costs due to maintenance and operations of integrations solutions
      Options:
           Point-to-Point
               No architecture costs, high development, high operations
           Service-Oriented Integration
               High architecture costs, low development, low operations
                o    Lower Total Cost of Ownership
                o    Less to build, less to maintain


      Architecture Costs
               Licenses
               Operation platform, servers
               Cost of implementing architectural hardware & software
               Design, installation, configuration (fail-over/load-balancing)
               First project will take the ‗hit‘ of initial costs
               ROI only appears in later projects
                                                                                       Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                  OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                                            Wednesday, June 16, 2010



      Development Costs
                                        Reduced number of interfaces
                                        Reusable adapters


                                                                                              Service Oriented
                                                    Point to Point
                                                                                                  Integration




                                                                                                          EAI




                                                    n(n-1) = 12
                                                                                                      2n = 8




                                              500
                                              450
               Number of integration points




                                              400
                                              350
                                              300
                                              250
                                              200
                                              150
                                              100
                                              50
                                               0
                                                     2   3   4   5   6   7   8   9   10 11 12 13 14 15 16 17 18 19 20 21
                                                                                 Number of systems



      As can be seen above the long term benefits from adopting a service oriented approach can
      save a lot of time and money compared to continuing with point to point interface
      development.
                                                               Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                          OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                    Wednesday, June 16, 2010




      4.3 PHASE 1 – FAULT MANAGEMENT AND PERFORMANCE
          MANAGEMENT
      Fault Management platforms and Performance Management Platforms would be the first
      areas to focus on. Once a significant number of systems are integrated via common services
      it becomes possible to create ‗composite‘ Services by reusing the existing tools to add new
      business value.


      Phase 1 (Implement all integrations related fault management and performance
      management)
           Application integration infrastructure project
                  Analyze security and networking constraints
                  Create installation & configuration guide for development, testing and production
                   environment
                  Install integration platform components on different servers based on guide
                  Configure integration platform and components based on guide
           Integration Element Manager Fault Management (partially based on POC)
                  Project Start Up
                  Detailed Integration Analysis
                   o     Analyze current information flows
                   o     Determine triggering events
                   o     Determine functions that need to be performed by integrations
                   o     Create work breakdown structure of integrations
                   o     Select integration touch points
                   o     Create detailed conceptual integration design
                  Realization of the integrations
                   o     Build integrations
                   o     Create Web Services and messaging interface
                   o     Unit Testing
                   o     Implement code changes based on test results
                  Testing and Deployment
                   o     Integration Testing
                   o     Implement code changes based on test results
                   o     Deployment to production environment


   4.3.1 BUSINESS BENEFITS


                      Fault and Performance Management Integrations allow simplification of the
                       Operating Centre Screen real estate
                      Decoupling from vendors, no need to buy their Network Management Products
                       when you can manage their Element Managers directly and avoid additional
                       licencing costs.
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                      OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                Wednesday, June 16, 2010



                 Multiple Technologies on on screen
                         Optical (SDH/DWDM)
                         Voice Switching
                         IP Infrsstructure
                         Access Infrastructure
                         Server farms (FTP & Web Storage, Mail Platform, DNS, DHCP etc…)
                         Service Related problems
                 Allows Correlation of different Technologies i.e. SDH Trunk failure affecting Voice
                  Trunk on Switch.
                 Reduced training costs for first line NOC staff as only need one screen to monitor
                  multiple technologies.
                                                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                        OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                                                              Wednesday, June 16, 2010




      4.4 PHASE 2 – CONFIGURATION MANAGEMENT AND PROCESS
          AUTOMATION
      Configuration Management and the automation of it can be automated by ensuring
      configuration change messages are tracked against a model of the Service Infrastructure.
      There are several processes using configuration management and other processes which
      when automated can allow operational efficiencies and more service up time.




                                                                                                             Change
                                                                                                             request
                                           Change
                                                                     Change       Architecture and
                                         Management                  request          Design
                                           System



                                                          Apply changes
                                           Emergency        to model                   Modelling
                                                                                                                                            Capacity
                                            Change
                                            request
                                                                               Configuration                                                Planning
                                                                               Management
                                                                                                                       Modelling
                                           Trouble
                                          Ticketing
                                                                                Database
                                           System
                 Exception                                       Devices
                  Change                                                                Network
                 Notification

                                                                                                     Inventory
                                Faults                                                              Management
                                                Discovery of                                          System Configuration
                                                unauthorized
                                                  changes
                                                                                                               Management
                                                                                                                 System
            Network                                                            Impementation of changes to                                 Performance
           Management                                                           the network based on model                                 Management
             System                                                                                                                          System




                                              Discovery
                                                                               Network
                                                                                                                              Collecting
                                            Events




                                                                                        Network




   4.4.1 BUSINESS BENEFITS


                                        Automated Configuration Management reduces the amount of human
                                         error from unplanned and unscheduled changes
                                                             Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                         OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                   Wednesday, June 16, 2010



                             Keeps accurate records of every device current configuration
                             Governance of Change Process – who made what change when i.e Audit
                              Trail
                             Reduce time to restore outages when accurate information on
                              configuration is at hand
                             Ability to roll back to last working configuration for failed changes
                             Ability to suppress Alarms for Configuration Devices under Planned
                              Change.
                                                          Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                       OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                 Wednesday, June 16, 2010




      4.5 PHASE 3 – OSS/BSS INTEGRATIONS AND SERVICE
          MANAGEMENT
           Integration Service Management
               Select organizational structure
               Define roles and responsibilities
               Create Service decompositions
               Define operational practices and procedures
               Establish support guidelines and expectations
               Establish monitoring and notification procedures
               Establish, administer, certify and deploy environments
               Define SLA‗s on both IT and Business Process level
           Integration OSS & BSS integrations
               CRM integration & IVR integration for Major Service Outages




      Once all the OSS systems fuctional logic is exposed via services with some workflow manual
      tasks such us sending information on major service outages to both Customer CRM and IVR
      type systems becomes possible saving time for call agents and limiting the incoming tide of
      customer complains. Self Care and pre-emptive information for clients makes customer
      operations much more efficient and therefore cost effective.
                                                             Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                         OSS Integration Roadmap – Gaining Business Value from SOA


                                                                                                   Wednesday, June 16, 2010



           Self Care Integration




      Further projects can be defined and planned based on sound business needs and a suitably
      strong business case.




   4.5.1 BUSINESS BENEFITS
                 Make Network and Service Related information accessible to front line Customer
                  Agents
                 Make Service related information directly accessible by customers reducing the
                  volume of incoming call traffic to call centres.
                         Reduces call durations doe incoming calls
                 Service Management integrations allows information from CRM and Call Centre
                  ACD/IVR systems to be used to give service related information to Operation
                  Centre staff.
                         Quicker advanced warnings to Call Centres from Operations
                 Service Related Performance Reporting capability
                                                                 Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                                              Glossary


                                                                                                      Wednesday, June 16, 2010




   5 GLOSSARY
      5.1 DEFINITIONS

      Definition          Description
      BPEL4WS             Business Process Execution Language for Web Services (BPEL4WS) is an XML-based
                          language for describing portable business processes.
      BPML                Business Process Modeling Language (BPML) is an extensible markup language
                          developed by the BPMI as a means of modeling business processes.
      BSS                 Business Support Systems
      CORBA               Common Object Request Broker Architecture (CORBA) is a standard defined by the
                          Object Management Group enabling software components written in multiple computer
                          languages and running on multiple computers to interoperate by wrapping code into a
                          bundle containing information about the capabilities of the code inside and how to call
                          it.
      CMIP                Common Management Information Protocol. ISO/OSI ITU-T X.700 network
                          management model defining the communication between network management
                          applications and management agents
      CMISE               Common Management Information Service Element (OSI & X.710/ISO 9595)
      EAI                 Enterprise Application Integration
      ESB                 Enterprise Service Bus
      eTOM                enhanced Telecom Operations Map
      HTTP                Hypertext Transfer Protocol a method used to transfer or convey information
                          originaly to provide a way to publish and retrieve HTML pages on the World
                          Wide Web
      HTTPS               HTTP over an encrypted Secure Sockets Layer (SSL) or Transport Layer
                          Security (TLS) transport mechanism providing a more secure transfer method
                          for HTML
      JAVA RMI            Java Remote Method Invocation API, a Java application programming
                          interface for performing the object equivalent of remote procedure calls
                          (RPC).
      JCA                 J2EE Connector Architecture, Java-based solution for connecting application
                          servers and enterprise information systems
      JMS                 Java Message Service, Java Message Oriented Middleware API for sending
                          messages between clients
      Loose               Loose coupling is the approach where integration interfaces are developed
      coupling            with minimal fixed constraints between the sending/receiving parties, thus
                          reducing the risk that a change in one application/module will force a change
                          in another application/module.
      NGOSS               New Generation Operating Systems and Software
      OSS                 Operational Suport Systems
      OSS/J               The OSS through Java initiative initiated by Sun Microsystems
      SID                 NGOSS Shared Information/Data model
                                                                  Roadmap to an improved OSS IT infrastructure using SOA
G Spice Consulting Ltd.                                                                                                Glossary


                                                                                                        Wednesday, June 16, 2010



      SOAP                The Simple Object Access Protocol (SOAP) is an XML based object protocol for the
                          exchange of information in a decentralized, distributed environment. It consists of an
                          envelope that defines a framework for describing what is in a message and how to
                          process it, a set of encoding rules for expressing instances of application defined data
                          types, and a convention for representing remote procedure calls and responses. All
                          encoding is in XML.
      SNMP                The Simple Network Management Protocol (SNMP) is an application layer protocol that
                          facilitates the exchange of management information between network devices. It is
                          part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite.
                          SNMP enables network administrators to manage network performance, find and solve
                          network problems, and plan for network growth.
                          Two versions of SNMP exist: SNMP version 1 (SNMPv1) and SNMP version 2 (SNMPv2).
                          Both versions have a number of features in common, but SNMPv2 offers
                          enhancements, such as additional protocol operations. Standardization of yet another
                          version of SNMP—SNMP Version 3 (SNMPv3)—is pending. This chapter provides
                          descriptions of the SNMPv1 and SNMPv2 protocol operations. Figure 56-1 illustrates a
                          basic network managed by SNMP.
      TMF                 TeleManagement Forum
      UDDI                Universal Description, Discovery and Integration (UDDI) is a specification proposed by
                          IBM, Microsoft and Ariba which is intended to provide a standard way means for
                          unique entities to describe and promote themselves as web services. UDDI provides a
                          comprehensive mechanism for locating services at run time by storing service
                          interfaces in their
                          WSDL format.
      WSDL                Web Services Description Language (WSDL) allows for formal description of the
                          interface to a web service, i.e. the format of XML messages that the service processes
                          and emits. It is ideally suited to SOAP-based services, but can be extended to XML
                          messages delivered via other protocols.
      XML                 XML stands for eXtensible Markup Language. This is a language for tagging and
                          formatting ASCII data for exchange between disparate applications and between
                          applications and human interfaces.




      5.2 REFERENCES

       D. A. Chappell & T. Jewell; Java Web Services, O‘Reilly 2002

       R. Monson-Haefel & D. A. Chappell; Java Message Service, O‘Reilly 2002

       TeleManagement Forum; Enhanced Telecom Operations Map 5.0 GB921; TMF 2005

       Cisco CCO Documentation