ORIGINAL PAPER

Design and implementation of Web Services-based NGOSStechnology-specific architecture

Mi-Jung Choi & Hong-Taek Ju & James W. Hong &

Dong-Sik Yun

Received: 20 June 2007 /Revised: 30 October 2007 /Accepted: 26 December 2007# Institut TELECOM and Springer-Verlag France 2008

Abstract To cope with frequent changes and functionaladditions of operation and support systems (OSSs), a guidelineof OSS’s architecture and development methods is needed.TeleManagement Forum has provided Next GenerationOperations Systems and Software (NGOSS) technology-neutral architecture (TNA), which describes major conceptsand architectural details of the NGOSS architecture in atechnologically neutral manner. The TNA can be mappedonto technology-specific architectures (TSAs) using specifictechnologies such as Extensible Markup Language, Java, andCommon Object Request Broker Architecture. Web Service,a distributed and service-oriented computing technology, canbe also applied to NGOSS TSA. In this paper, we provide adesign and implementation of Web Services-based TSA inaccordance with the architectural principles of TNA and theperformance evaluation of our proposed system. Our workcan be used as a guideline for anyone planning to develop aWeb Services-based NGOSS TSA.

Keywords NGOSS . TNA . TSA . CCV.

Framework services . Contract .Web Services

1 Introduction

The number and complexity of communication serviceshave exploded in the last few years and this trend will likelycontinue in the near future. Due to a rapid evolution oftelecommunication technologies, products and services arealso multiplying. Moreover, as the data communications,telecommunications, and other forms of communicationconverge, the complexity and size of networks that supportthe growing number and range of services is quicklyincreasing. The rapid growth of the Internet and theconvergence of communication networks have become themain drivers for a flexible and scalable operations supportsolution for today’s telcos’ services and systems [1]. Forthis reason, TeleManagement Forum (TMF; http://www.tmforum.org/, refer Oct 2007) has proposed a NextGeneration Operations Systems and Software (NGOSS) [2]framework to improve the management and operation ofinformation and communication services. The goal of NGOSSis to facilitate the rapid development of flexible and low-costownership, as well as Operations and Business SupportSystems (OSS/BSS) solutions to meet the business needs.

The service proliferation requires that new generationOSS/BSS architectures must be capable of fulfilling awhole new set of unprecedented requirements that will arisedue to the rapid service development. Irrespective ofapplications, platforms, or technologies, OSS architecturesmust be able to:

– Define service components with various attributes– Support short service development cycles

Ann. Telecommun.DOI 10.1007/s12243-008-0019-4

M.-J. Choi (*) : J. W. HongDept. of Computer Science and Engineering, POSTECH,Pohang, South Korea 790-784e-mail: mjchoi@postech.ac.kr

J. W. Honge-mail: jwkhong@postech.ac.kr

H.-T. JuDept. of Computer Science, Keimyoung University,1000 Sindang-Dong, Dalseo-Gu,Daegu, South Korea 704-701e-mail: juht@kmu.ac.kr

D.-S. YunKT network technology laboratory,463-1, jeonmin-dong, Yuseong-gu,Daejeon, South Koreae-mail: dsyun@kt.co.kr

– Avoid service introduction delay, i.e., rapid launch ofnew services

– Deliver new services or service bundles in a scalable,repeatable manner without massive duplication ofeffort

– Automate configuration management to facilitate fasterinstallation rates

The TMF’s NGOSS technology-neutral architecture(TNA) [3], which is sustainable through technologychanges, satisfies these requirements. NGOSS TNAdescribes major concepts and architectural details of theNGOSS architecture in a technologically neutral mannerand emphasizes a service-oriented approach based onintegration of well-defined collaboration contracts. It alsotargets the use of commercial off-the-shelf (COTS) infor-mation technologies, instead of technologies unique to thetelecommunications industry, as many legacy managementsystems have done in the past. This approach significantlyreduces costs and improves software reuse and operationalflexibility, enabling NGOSS-based systems to support arange of new services and new technology environmentsmore easily.

The TNA can be mapped to specific technologies for thepurpose of implementing and deploying an NGOSS system.The separation of technology-neutral and technology-specific architectures (TSAs) enables OSS developers tochoose the ‘best-fit’ management components and technol-ogies for their management capability. TMF has proposedthree technology application notes that describe the map-ping of TNA onto specific technologies such as ExtensibleMarkup Language (XML) [4], Common Object RequestBroker Architecture (CORBA) [5], and Java [6]. However,these application notes do not explain detailed applicationmethods of technologies to the TNA components or anyimplementation guidelines.

Web Service (WS) [7], an emerging technology with thepowerful support of standardization, is a promising solutionfor NGOSS TNA. Web Service is a distributed and service-oriented computing technology with strong support that isfreely available from the industry. Therefore, it satisfies theservice-oriented architecture (SOA) of NGOSS and sup-ports COTS tools that can be applied to NGOSS TNAcomponents [8]. The adaptation of the SOA to create anenvironment, where there are granular and loosely coupledOSS components with standardized interfaces, can plug andplay over a common infrastructure [1]. In this paper, wesummarize the state-of-the-art NGOSS architecture. Wepropose a technology-specific architecture using WebServices in accordance with TNA principles [3] andprovide detailed application methods and implementationdetails using Web Services technologies. We also presentperformance evaluation results and determine a bottleneck

component in our Web Services-based system. We hopethat our work can be used as a guideline for anyoneplanning to develop a Web Services-based NGOSS TSA.

The organization of this paper is as follows. In Section 2,we give an overview of NGOSS architecture with NGOSSTNA and TSAs. Section 2 also investigates three technol-ogy application notes. In Section 3, we examine thealignments with NGOSS TNA using Web Services tech-nologies and describe our design of Web Services-basedTSA. In Section 4, we demonstrate a case study. In Section5, implementation details of Web Services-based TSA inaccordance with the case study are given. Section 6 showsperformance evaluation results of our system and shares ourexperience for implementing a Web Services-based NGOSSsystem. Finally, we conclude our work and discuss possiblefuture work in Section 7.

2 Overview of NGOSS architecture

In this section, we first briefly describe an overview ofNGOSS and NGOSS TNA. Next, we summarize threetechnology application notes of TSA proposed by TMF andOSS/J initiative.

2.1 NGOSS framework

NGOSS [2] is a comprehensive and integrated frameworkfor developing, procuring, and deploying operational andbusiness support systems and software that enable serviceproviders and their suppliers to automate business processesand have the agility to respond to ever changing customerneeds and market landscapes. TMF has developed NGOSS asa toolkit of industry-agreed specifications and guidelines thatcover critical business and technical areas. Figure 1a illustratesthe NGOSS framework and four views [2]. Conceptually,there are four quadrants, each representing the aspects ofdefining, designing, implementing, and operating an NGOSSsolution which are termed as Business, System, Implemen-tation, and Deployment views, respectively. A key advantageof this approach is that it provides traceability from businessdefinition of the solution through its architecture, implemen-tation, and deployment specification.

In this paper, we focus more on the System andImplementation views. The System view is primarilyconcerned with the modeling of system processes andinformation in a technologically neutral manner. The SharedInformation Model (or SID) [9], an outcome of the Systemview, defines the shared data and information elements ofNGOSS, addressing the information and communicationservice industry’s need for shared information–data defini-tions and models. The Implementation view focuses on howto build hardware, software, and firmware that will imple-

ment the system being designed. This view uses a particularNGOSS architectural style to map from the technologicallyneutral specification of the system to the selected targetarchitecture.

Figure 1b shows the detailed architecture of NGOSSTNA in the System view of NGOSS framework in Fig. 1a.The NGOSS TNA [3] is the basic concept and componentof NGOSS architecture. The core components of TNA arecommon communications vehicle (CCV), services, andcontract. The service modules can communicate with eachother through CCV [3], which is a generalized message busthat is independent of a specific technology. The CCV isresponsible for the transport of information among appli-cation objects. The services are mainly divided into twoparts: business services and framework services [3].Business services provide the application level functionalitythat directly supports the implementation of a businessprocess such as Service Level Agreement management,billing mediation, quality of service (QoS), etc. Frameworkservices provide the infrastructure necessary to support thedistributed nature of the NGOSS TNA. For example, theyinclude naming and directory services, messaging services,and transaction management–monitoring services.

The mandatory framework services consist of repository,registration, location, and naming services. The registrationservice provides services and functionality required tosupport location transparency. The repository serviceprovides a logical view of all information on a deployeddistributed system. The naming service is responsible forgenerating and resolving unique names for the variousentities contained in the repository. The location service,often built on the naming service, provides a means to mapa request for an object to its particular instance.

An NGOSS contract is the fundamental unit of interop-erability in an NGOSS system. A contract is used to definea specification of a service to be delivered, as well as tospecify information and code that implement the service. Inshort, a contract is a way of reifying the specification andimplementing the functionality of the service including

obligations to other entities in the managed environment.Thus, it is much more than a container of data or aspecification of a set of methods.

The insulation of system architecture from technology-specific details provides a number of related benefits [3].First, it ensures the validity of the NGOSS architecture overtime by supporting the deployment of new technologieswithout having to rearchitect the entire OSS solution.Second, it provides the architectural underpinnings for thesimultaneous use of multiple technologies in a singleintegrated OSS environment, supporting legacy systemsand enabling technology migration over time. Finally,insisting that the architecture remains technology neutralhelps to prevent system design decisions from being takentoo early in the development lifecycle. An excess of designdetail in the core of the architecture would make it moredifficult to find technologies for implementation.

The core architectural principles to be examined for thealignment of the NGOSS TNA and TSA are as follows.First, the architecture needs to provide distribution support.The architecture provides communication between businessservices and between process control and other systemservices. Second, the architecture should support theseparation of business process from software implementation.Finally, the OSS needs to provide shared information formanagement information model. To design a technology-specific architecture, the technology must align with theseNGOSS architectural principles.

2.2 Technology-specific architecture

TMF has applied two technologies, namely XML [4] andCORBA [5], to the NGOSS TNA and specified technologyapplication notes. The OSS/J initiative 0 proposed Javatechnology as a specific technology for TNA. Theapplication notes present requirements of NGOSS TNA,overviews of each technology, and a guideline to directtechnology maps to the concepts of the TNA. In thissection, we present the alignment of NGOSS TNA and

a b

System

s

View

BusinessView

Implem

entation

View

Deploym

ent

View

NGOSSNGOSSKnowledgeKnowledge

BaseBase

Share

d Data

(SID

) &

Technolo

gy Neu

tral

Archi

tect

ure (

TNA)Contract Interface &

Technology Specific

Architecture(TSA)

Complia

nce

Tests

Business

Process Map

(eTOM)

Fig. 1 NGOSS framework(a) and TNA (b)

compare three TSAs using specific technologies: XML,CORBA, and Java. Table 1 [8] shows the comparison resultof three technologies in accordance with the requirementsof NGOSS TNA.

XML has a natural affinity with communication man-agement. Using XML to validate, manipulate, and definethe structure of application-specific information modelsusing general-purpose tools is an attractive possibility.However, XML has a substantial overhead associated withthe text-only encoding of data. Also, XML–HTTP solutionssuffer from the lack of availability of common distributedprocessing support services provided by more matureplatforms such as CORBA and J2EE services [4]. CORBAis a distributed processing platform and thus supports thecommunication method and framework services for distrib-uted processing. It also supports the interface definitionwith specifying CORBA Interface Definition Languages.However, CORBA does not provide information modeling;hence, it can define the shared information using XML orother languages [5]. J2EE directly implements the princi-ples of the NGOSS TNA such as the distribution supportand separation of business process from implementation.However, J2EE architecture does not have any explicitsupport for the concept of shared information or federatedinformation services as defined in NGOSS TNA [6].

3 Web Services-based NGOSS TSA

In this section, we examine the principles of NGOSS TNAand alignments with NGOSS TNA using Web Services andpropose our Web Services-based TSA. We focus onapplication methods of Web Services technologies to theprinciples and components of NGOSS TNA.

3.1 Alignments with NGOSS TNA using Web Servicestechnologies

In this section, we examine the Web Services technologiessuch asWeb Services Description Language (WSDL), SimpleObject Access Protocol (SOAP), Universal Description,

Discovery, and Integration (UDDI), and Web Servicesbusiness process execution language (WS-BPEL), and howthey are mapped, satisfying the principles of NGOSS TNAmentioned in Section 2.1.

Web Services technologies are best described as aframework of self-contained, modular applications thatcan be discovered and executed over the network byremote programs. Web Services allow searching forservices and listing of the services and contract details forfurther information using the Web Services registry,normally based on the UDDI [10]. The detailed informationof the services is written in WSDL [11]; an XML documentformat for describing Web Services. The requests andresponses between client and remote Web Services aregenerally carried out by the exchange of SOAP [12]messages protocol. WS-BPEL [13] is used to describeservice flows which show how service-to-service commu-nications, collaborations, and flows are performed. TheseWeb Services technologies are applied to NGOSS TNAcomponents such as CCV, framework services, and contractto meet the principles of NGOSS TNA.

The information model is designed to be more than just astandard representation of data—it also defines semanticsand behavior of, and interaction between, managed entities.The NGOSS SID model [9] provides the industry with acommon vocabulary and set of information–data definitionsand relationships used in the definition of NGOSSarchitectures. The XML Schema allows us to define thestructure of management information with richer definitionsof data types of XML documents including complex anddata-centric types. The XML Schema also allows inheri-tance relationships between elements. Based on our definedXML Schema, we can define management operations andmessages written in WSDL. By representing OSS/BSS dataas XML, the myriad data formats used in any given OSS/BSS implementation can be integrated without requiringchanges to the current system data models. With dataintegrity errors at the root of many OSS/BSS problems, onebenefit of using XML is the framework it provides forexecuting sophisticated data validation and conversion fromone model to another.

Table 1 Comparison of specific technologies: XML, CORBA, and JAVA

Alignment XML CORBA Java

Communication HTTP, SOAP GIOP, IIOP RMI-IIOP, JMSFramework services Runtime discovery service: UDDI CORBA services (naming,

trading, etc.)Runtime discovery service:JNDIRuntime location of information: XPath,

XLink, XPointerBusiness processmanagement

Not specified Define new services Define business processcomponent

Contract interface XML definition CORBA IDL Java interfaceShared information XML Schema (informationadaption: XSLT) Can be defined by IDL Not specified

The second requirement of the NGOSS TNA is toprovide distribution transparency. The NGOSS systemneeds a communication mechanism and repository thatrecords the information used during system execution. Thisrequirement is achieved by CCV and framework servicesconsisting of registration, repository, naming, and locationservices. UDDI provides a comprehensive mechanism forlocating services at run time by storing service interfaces intheir WSDL format.

UDDI registration information is comprised of five datastructure types: businessEntity, businessService, binding-Template, tModel, and publisherAssertion. The businessEn-tity describes the business or other entity for whichinformation is being registered. We can define serviceprovider and consumer in management processes as thebusinessEntity. The businessService is the name anddescription of the services being published, which can beservice information with service name, service publisher,etc. The bindingTemplate is information of the serviceincluding an entry-point address for accessing the service,which is used as operations binding information for theservice access. The tModel is a collection of informationthat uniquely identifies the service specification. We canuse the tModel to store contract information, provide top-level searches of contract-based tModel data structure anddefine a contract in a WSDL format. We do not use thepublisherAssertion, which is a relationship structure thatassociates two or more businessEntity structures.

Service providers can use UDDI to register and advertisethe services they offer. Service consumers can use UDDI todiscover services that suit their requirements and obtain theservice metadata needed to consume those services.Application programs can search the UDDI repository tofind the interface that they require, download the WSDLdescription, and use the binding information to communi-cate with the interface over a suitable communicationchannel. UDDI supports basic functionalities of frameworkservices such as repository, registration, and locationservices. Thus, UDDI can be served as framework servicesof NGOSS TNA.

The requirement of separating business process fromsoftware implementation is achieved by the definition ofcontract and process. The contract, which is a definition ofthe service specification and message specification betweenservice components, can be defined in WSDL based on themanagement information model in XML Schema format.WSDL is an XML document format for describing WebServices as a set of endpoints operating on messagescontaining either document-oriented or procedure-orientedmessages. The operations and messages are describedabstractly and then bounded to a concrete network protocoland message format to define an endpoint. We can definefunctional parts of the contract including input, output,

conditions, etc. with WSDL. WSDL is sufficiently exten-sible to allow description of endpoints and their messagesregardless of the message formats or network protocolsused for communication.

The business process can be defined by WS-BPEL withthe concept of process entities, process sequences, andinteraction messages. Based on XML, WS-BPEL is nowemerging and widely used in the industry as the standardfor defining and executing business processes. Thus, wechoose WS-BPEL as the process sequence definition. WS-BPEL includes four major sections in defining a businessprocess: The <partnerLink> section defines the differentparties that interact with the management process in the courseof processing the configuration. The <variables> sectiondefines the data variables used by the process. Variablesallow processes to maintain state data and process historybased on the exchanged message. The <faultHandler>section defines the activities that must be performed inresponse to faults resulting from the invocation of services.The <sequence> section allows defining a collection ofactivities to be performed sequentially in a lexical order.

We can define the relations among the systems, manage-ment processes, management messages, and exceptionhandlings using WS-BPEL. The service provider andconsumer can be defined in the <partnerLink> section, andthe contract with management operations, messages, and con-ditions in a WSDL format can be defined in the <variables>section. The management sequences in accordance with themanagement scenario are defined in the <sequence>section. Due to BPEL-enabled tools, designing, testing,and deploying business processes have become muchsimpler, even for nonprogrammers. This means businessprocesses can be easily modified, making the operator moreagile at automating costly operations or leveraging newbusiness opportunities.

In general, Web Services are XML-based technologiesthat connect systems via Web. Thus, Web Services-basedTSA is technically not much different from the applicationnote of XML, which does not describe the details ofapplying XML technologies to NGOSS TNA.

3.2 Architecture

Web Services include many standard specifications. InSection 3.1, we examined the alignments with NGOSSTNA using Web Services technologies. We focus more onthe NGOSS specification from a Web Services perspective.Figure 2 shows our Web Services-based TSA. Ourarchitecture is extended from the TNA architecture usingWeb Services technologies. SOAP is used as CCV to com-municate between process entities, and WSDL is used todefine contracts between process entities through SOAP.UDDI supports the framework services of repository,

registration, naming, and location services while WS-BPELsupports the process service that executes the managementfunctions including framework services.

The policy service can use the definition of WS-Policy[14] as the definition of information and policy manager asthe engine. The security service can use the WS-Securityspecification [15] as the definition of information andsecurity manager as the service engine. The managementoperation services such as service assurance, servicedelivery, and so on can be defined as new services usingWSDL. The adapter acts as a message handler with aSOAP client module while XML database (XMLDB) canbe used as the management repository instead of thetraditional relational database management system. Thenative XMLDB stores the data structured as XML withouthaving to translate the data to a relational or object databasestructure, which is especially valuable for complex andhierarchical XML structures that would be difficult orimpossible to map to a more structured database. However,the XMLDB is not mandatory due to the performanceissues of processing XML document.

4 Practical use of Web Services-based TSA

In this section, we present a case study to verify ourtechnology-specific architecture. We have selected theprocess of digital subscriber line (DSL) fulfillment, whichis one of the examples of Enhanced Telecom OperationsMap’s (eTOM) fulfillment process, as a sample case toverify our technology-specific architecture. The eTOMfulfillment [16] is a vertical end–end process groupingresponsible for providing customers with their requestedproducts in a timely and correct manner. It translates thecustomer’s business or personal need into a solution, whichcan be delivered using the specific products or services inthe enterprise. This process informs the customers of thestatus of their purchase order, ensures completion on time,

as well as ensuring a delighted customer. In this section, wedefine management information and process sequences forDSL fulfillment.

4.1 Management information

As explained in Section 3.1, we define our managementinformation through XML Schema based on SID modeling[9]. The SID specification defines the business entities andtheir characteristics including data type, description, andwhether they are required or optional. Figure 3 shows theXML Schema defining the information model of customer,product, and customer order. The information of customerorder references one customer and one or more products.The product includes the product name, description,product number, manufacturer, valid period, and lifecyclestatus. The customer contains the customer ID andcustomer status as mandatory elements. The customer ordercontains all contents of the customer and product and refersto each type defined as the complex type of customerTypeand productType, respectively. The customer order alsocontains an assigned priority (order handling priority) and

WS-SecuritySecurity Manager r

WS -B P E LWS-Policy

Policy ManagerUDDI

XMLDBSOAP Engine

CCV R epo sitoryRepository

PolicyService

NamingService

contractAdapter

contractAdapter

LocationService

contractAdapter

RegistrationService

contractAdapter

RepositoryService

contractAdapter

Delivery

SecurityService

ProcessService

ServiceAssurance

Management

Management

Service Service Quality

OSSInformation

ManagementWorkforce

Management

Facility Access Domain

ManagementManagement

NetworkManagement

WSDL

Message Handler &

SOAP Client

contract

contract

Adapter

Adapter

contractAdapter

contractAdapter

contractAdapter

contractAdapter

contractAdapter

contractAdapter

contractAdapter

contractAdapter

Shared Message Bus

Fig. 2 Web services-based TSA

Fig. 3 Shared information of DSL fulfillment

assigned response date (order response date) as attributes.We define all management information such as serviceparameter, service order, resource parameter, and resourceorder followed by the SID modeling [9].

4.2 Management process

There are Order handling module, Service configuration &activation module, and Resource provisioning module inthe management system for DSL fulfillment. The Orderhandling module receives the customer order request ofDSL service from a customer and then sends the serviceorder request to the Service configuration & activationmodule. The Service configuration & activation modulerequests the resource provisioning to the Resource provi-sioning module in order to acquire the resource after theservice configuration in accordance with the servicerequest. After acquiring the resource, the Service configu-ration & activation module activates the service and reportsthe result of service activation to the Order handlingmodule.

Figure 4 shows the combination of interaction sequencesbetween framework service components and the sequencefor the service order. That is, there should be a process tomake a contract between two modules for the Orderhandling module in order to request the service order tothe Service configuration & activation module. In theprocess of making this contract, the Order handling modulebecomes a consuming contract instance, and the Serviceconfiguration & activation module becomes a providingcontract instance. When the contract between the Orderhandling module and the Service configuration & activa-tion is agreed with, the service requester (the Order

handling module) can send the service order request tothe service provider (the Service configuration & activationmodule).

Figure 5a defines the sample scenario in Fig. 4 usingWS-BPEL. First, we define the process entities in thepartnerLinks, messages from senders and receivers in thevariables, and management faults in the faultHandler. Wealso define the process sequence that is executed when themessages from some partnerLinks arrive in the Sequence.

We have defined the contract of the system view in theXML format. The most important part in five parts ofcontract (General, Functional, Non-functional, Managementand View specific) is the functional part, in which input andoutput variables and conditions need to be defined. Figure5b describes the system view contract of ‘RequestCusto-merOrder’ between the Order handling module and theService configuration & activation module for the DSLfulfillment in the XML format. The General part containsContract names, Versions, and explanations while theFunctional part contains Pre-condition, Post-condition,Input & Output Parameters, and so on. The Non-Functionaland Management parts need to be defined when it isnecessary to extend the capability of QoS, policy, cost, andmanagement.

5 Implementation of Web Services-based TSA

In this section, we present the implementation details of ourWeb Services-based TSA. We have implemented TNAcomponents and management functions using Web Servicestechnologies based on our proposed design and named ourOSS system as Web Services-based OSS (WS-OSS).

Orderhandling

Service conf.& activation

Resource provisioning

customerRequest order

Issue customer order

Request service order

Issue service order

Configure & activate service

Request resource

Issue resource order

Manage & track customer

Response & manage service

Response & report service order

Repositoryservice

Registrationservice

Contract instancelocation service

Register consuming contract instanceAdd contract instance to repository

Request instance of providing contract

Request instance of providing contract

Respond with instance of providing contract

Located instance of providing contract

Located instance of providing contract

Resource provisioning

Register consuming contract instanceAdd contract instance to repository

Request instance of providing contract

Request instance of providing contract

Respond with instance of providing contract

Fig. 4 Management scenario ofservice order

Our WS-OSS system has been implemented on a Linuxserver. We used the Apache Tomcat 4.0 for the Web serverand Servlet engine. The Apache Web Services projectpackage [17], which is a Java-based Web Services software,is also used. We used jUDDI 0.9rc4 for a UDDI imple-mentation, Axis 2 v1.0 for a SOAP engine, ApacheAddressing for a WS-Addr handler, and Pubscribe 1.0 fora Web Services notification handler. In addition, AgilaBPM is used for a BPEL engine and Xindice v1.0 for anXMLDB. Figure 6 shows the implementation architectureof our WS-OSS system.

The Adapter module of the rectangle in Fig. 6 acts as agateway for communication and message handling. TheAdapter is implemented with Axis package; it uses a SOAPclient module for requesting data to the other servicemodules and a SOAP server module for receiving notification

from other service modules. In our implementation, the rolesof CCV are distributed into the Adapter module. Using thisadapter approach, we can integrate the existing OSS systeminto our WS-OSS with other types of clients and notificationhandlers. In the case of the same management protocol(SOAP request), direct requests without going through othertypes of clients and notification handler are performed onlythrough the SOAP client and server. In our WS-OSS system,we concentrate more on framework services and TNAcomponents such as CCV and contract. We do not considerthe policy and security services modules.

We first implemented the framework services usingexisting UDDI application programming g interfaces(APIs). The naming service checks the registration infor-mation and service name using the get_registeredInfo API,which provides a summary of all information registered on

a

b

Fig. 5 Service order:WS-BPEL definition (a) andcontract (b)

behalf of a specific user. The repository service provides anupdate of service information using publisher APIs such assave_business, save_service, save_binding, save_tModel,delete_business, delete_binding, etc. The registration ser-vice calls the repository service to register for the providedand consumed services. If it is necessary to check thenaming, then it calls the naming service. The locationservice provides service information search using inquiryAPIs such as find_business, find_service, find_binding,find_tModel, get_businessDetail, get_serviceDetail, etc.We omitted the request from the location service torepository service to inquire service information in Fig. 4by directly providing the search capability to the locationservice. This can reduce the operation calls and loads of therepository service.

Then, we deployed these framework service functionsinto Web Services using a Java Web Service provided byAxis. This deployment method automatically generates aWSDL file and proxy–skeleton codes for the SOAP remoteprocedure calls. In order to enable the existing Java class asa Web Service, we simply copied the Java file into theAxis Web application, using the extension ‘.jws’ instead of

‘.java’. We implemented framework services such asrepository, registration, location, and naming services usingthis mechanism. Unlike this mechanism, we first definedWSDLs, generated Java stubs, and filled the codes in thestubs. We implemented other services, namely, manage-ment function modules such as order handling, serviceconfiguration, etc., using the second method. Finally, wedefined the business process sequence in WS-BPEL, inwhich the defined process flows were stored in their ownprocess repository, and Agila BPM engine executed theprocess in accordance with the WS-BPEL definition.

The execution step of our order handling for a DSLfulfillment is as follows: A customer orders new DSLservice through the service application form of Web-baseduser interface. This request message is handed over to theBPEL engine, and the engine checks the request messageand the partnership. Then, it directly calls the orderhandling service. The management processes are conductedin the sequence of Fig. 4 and the BPEL engine processesthese management sequences. The contracts betweenframework services are interface level, which are operationsin a WSDL format called by each other. The contracts

UDDI (jUDDI)

CCV

XMLDB

(Xindice)

Repository(Store)

Contract(WSDL)

Adapter(Axis)

Repository

(MySQL)

Registration(Register)

Contract(WSDL)

Adapter(Axis)

Location(Discover)

Contract(WSDL)

Adapter(Axis)

Naming(Set&GetName)

Contract(WSDL)

Adapter(Axis)

WS-BPEL Engine(Agila BPM)

Contract(WSDL)

Adapter(Axis)

OrderHandling

Contract(WSDL)

Adapter

Service Configuration

Contract(WSDL)

Adapter

Service Activation

Contract(WSDL)

Adapter

Resource Provisioning

Contract(WSDL)

Adapter

ResourceAllocation

Contract(WSDL)

Adapter

Repository

(Xindice)

<Adapter>

HTTP Client

SOAP Client

getRequest

HTTP Server

SOAP Server

Other Notification Handlers

Notification InformationInformation for Request Management Information

Method Invocation

Result from Method

XML-encoded Notification Data

setRequest Notify

Other Clients

XML Parser & WS-Addr Handler

SOAP Engine (AXIS)

Fig. 6 Implementation architecture

between the management processes are registered andstored via registration and repository services, respectively,and preserved in the repository of UDDI itself.

6 Performance evaluation

In this section, we present performance evaluation results ofour system. We evaluate the processing time of each TSAcomponent and determine the bottleneck component. Wealso propose a method to reduce the processing overhead ofthe bottleneck component.

6.1 Performance test environment

Figure 7 shows our performance evaluation environment.We independently implemented a jUDDI server for theservices registration, an Xindice DB server for informationrepository, and a server for service consumers, serviceproviders, and a BPEL engine. We processed the DSLfulfillment in Fig. 4. As shown in the sequence diagram ofFig. 4, an actor can be a service provider or a serviceconsumer; thus, we implemented the service providers andconsumers in the server. As mentioned in Section 5, theservers were implemented on Linux OS with a Pentium-III2.4-GHz central processing unit and 1-GB random accessmemory using Java language and connected via 100-Mbpslocal area network.

6.2 Performance test result

In this section, we examine an NGOSS TSA componentwhich generates the biggest processing overhead. The WebServices-based NGOSS TSA is mainly composed ofcomponents such as a BPEL engine, a UDDI engine, anda DB server. We increase the concurrent service requestsfrom 1 to 100 by 25 and investigate the processing time ofeach component. The concurrent requests are generatedusing a thread mechanism.

Figure 8 shows the processing overhead of eachcomponent in accordance with the number of requests. Asthe number of requests increments, the UDDI engine which

processes framework services becomes the bottleneckcomponent. As mentioned in Section 3.1, each part ofcontract is mapped to the UDDI data structure and fourUDDI data structures such as butinessEntity, businessSer-vice, bindingTemplate, and tModel need to be registered tothe UDDI registry to define only one contract. Moreover,the search of a contract also needs to investigate four UDDIstructures. Thus, the UDDI engine generates more process-ing overhead as the number of simultaneous requestsincreases. In the case of only one customer’s request, theprocessing time of BPEL engine occupies the biggest of theentire processing time. However, as the number of requestsincreases, the portion of processing time of BPEL engine inthe entire processing time relatively reduces compared tothe processing time of UDDI engine. The processing timeof XMLDB is comparatively low because most DBoperations to process DSL fulfillment are insert operationsto add customer’s order and correspondent service infor-mation. The insert operation is relatively shorter than thequery operation in XMLDB.

6.3 Performance enhancement method

In this section, we investigate the performance enhance-ment method of processing time of UDDI registration andsearch, which generates the biggest processing overhead.To reduce the processing overhead of UDDI search, we use

Service Provider & Consumer,BEPL Engine

(2.4 GHz CPU, 1G RAM)

jUDDI Server(2.4 GHz CPU, 1G RAM)

DB Server(2.4 GHz CPU, 1G RAM)

100 Mbps

100 Mbps100 Mbps

Web UI(Client)

Fig. 7 Performance evaluationenvironment

Fig. 8 Processing time per component

a cache mechanism. Instead of sending UDDI searchoperations to the jUDDI engine every time the serviceconsumer requests, we can search the information for thesame service in the cache. This reduces the search overheadof UDDI registry. Figure 9 shows the comparison result ofprocessing time of UDDI search with and without the cachemechanism. As the result of applying the cache mechanismto the UDDI search, we gain 25% performance enhance-ment of processing time of UDDI. The enhancement byusing the cache mechanism is obtained only in the searchpart, not the registration part. To reduce the processingoverhead of registering contracts, we also need to devise amethod to merge many contracts into one.

To decrease the overhead of XMLDB, we consider theuse of a relational DB such as MySQL. We compared theprocessing time of Xindice DB and MySQL DB in terms ofinsert and query operations. Figure 10 shows the processingtime of adding and querying customer information to DB.We performed insert operations as the number of concurrentrequests increased from 1 to 200 by 50. The processingtime of insert operation in MySQL DB is roughly twice asfaster than that in Xindice DB. The processing time ofquery operation in MySQL slightly increase as the numberof insert request advances and remains almost staticregardless of the number of existing data. However, theprocessing time of query operation in Xindice increaseslargely as the number of data in DB advances. This isbecause Xindice uploads the entire XML data into memoryto parse. Thus, Xindice is not efficient when we need toprocess query operations with lots of data. Note that, thisperformance result is merely limited to Xindice XMLDB ofthe Apache group.

6.4 Experience and discussion

Web Service satisfies the characteristics of NGOSS SOAand supports COTS and freely available tools that can beeasily applied to NGOSS TNA components. Specifically,

the management information using XML Schema supportspowerful information definition. The contracts includingservice processors, pre–post conditions and input–outputmessages are also defined in WSDL. UDDI is used asframework services and SOAP acts as CCV. Moreover, themanagement scenario can be defined in WS-BPEL andprocessed in the BPEL engine. Partners in BPEL definitionare acted as service providers and consumers in UDDIrepository; operations, and messages in BPEL are mappedto messages and operations in WSDL. The messages inWSDL are also mapped to actions in SOAP. In this manner,Web Services technologies applied to each NGOSS TSAcomponent are connected and operated together. Conse-quently, Web Services technologies fully support theprinciples and functionalities of NGOSS TNA. That is, itis important to understand the relationship between theelements of each technology and define the elements toorganically operate services.

We have used four data structures of UDDI such asbutinessEntity, businessService, etc. to define the contractand implemented framework services using UDDI APIssuch as get_registeredInfo, save_business, save_servic,find_business, find_servic, etc. To register a contract, weneed to register four data structures by calling four saveoperations per each data structure, which generates muchprocessing overhead of service registration. This overheadis the same as the search operations. Thus, we have applieda cache mechanism to search operations of UDDI registryto reduce the search processing overhead. But, this is only atemporary solution. Ultimately, we need to revise themapping of contract to UDDI data structure towardsdefining a contract using one or two UDDI data structures.Also, we can use a relational DB instead of XML DB todecrease the overall processing time. XMLDB is helpful inmanipulating the data represented in XML format butrequires much processing time and computing power toparse XML data.

Fig. 10 Performance comparison of Xindice and MySQL

Fig. 9 Performance enhancement with cache mechanism

7 Concluding remarks

In this paper, we examined the concept, architecturalprinciples, and components of the NGOSS TNA. Weproposed an NGOSS technology-specific architecture usingWeb Services technologies in accordance with the princi-ples of NGOSS TNA. Web Service is a distributed andservice-oriented computing technology that can be appliedto the NGOSS TNA. We examined the advantage ofapplying Web Services technologies to NGOSS TNA. Tovalidate our proposed architecture, we implemented aprototype of Web Services-based TSA focusing on TNAcomponents such as CCV, framework services, and contractand management functions using the DSL Service OrderFulfillment example. We also presented performanceevaluation results, determined a bottleneck component inour system, and proposed a performance enhancementmethod using the cache mechanism. Our work can be usedas a guideline on how Web Services technologies areapplied to the NGOSS components, for anyone planning todevelop a Web Services-based NGOSS TSA.

We are currently extracting the performance metrics ofWeb Services-based TSA and conducting performanceanalysis. We need to implement other service modulessuch as policy and security services and will also extendour system with more management functions based oneTOM operations.

Acknowledgments This research was supported in part by theMinistry of Information and Communication, Korea, under theInformation Technology Research Center support program supervisedby the Institute of Information Technology Assessment (IITA-2006-C1090-0603-0045) and by the Electrical and Computer EngineeringDivision at POSTECH under the BK21 program of the Ministry ofEducation, Korea.

References

1. Georgalas N, Azmoodeh M (2004) Using MDA in technology-independent specifications of NGOSS Architectures. In: 1stEuropean Workshop on MDA (MDA-IA 2004). Enschede, TheNetherlands, Mar 2004, pp 11–18

2. TM Forum Technical Program (2006) New generation operationssystems and software (NGOSS), RN303 R6.0, Jun 2006

3. TM Forum (2005) NGOSS technology neutral architecture,TMF053 v5.3 r6.0, Nov 2005

4. TM Forum (2001) NGOSS phase 1 technology application note—XML, TMF057 v1.5, Dec 2000

5. TM Forum (2001) NGOSS phase 1 technology application note—CORBA, TMF055 v1.5, Aug 2001

6. Ashford C (2004) OSS through Java as an Implementation ofNGOSS, White paper, Apr 2004

7. W3C (2004) Web Services Architecture, W3C Architecture WGNotes, Feb

8. Choi M, Ju H, Hong J, Yun D (2007) Design of NGOSS TSAusing Web Services Technologies. In: Proc. of Integrated NetworkManagement Symposium (IM2007). Munich, Germany, May2007, pp 868–71

9. TM Forum (2005) Shared information/data (SID) model, GB 922,Release 6.0, Nov 2005

10. OASIS (2004) UDDI version 3.0.2, UDDI Spec TechnicalCommittee Draft, Oct

11. W3C (2001) Web Services Description Language (WSDL) 1.1,W3C WSDL WG Note, Mar

12. W3C (2003) SOAP Version 1.2 Part 1: Messaging Framework,W3C Recommendation, Jun

13. BEA Systems, International Business Machines Corp., MicrosoftCorp., SAP AG, Siebel Systems (2003) Business ProcessExecution Language for Web Services Version 1.1. Second PublicDraft Release, May 2003

14. W3C (2007) Web Services Policy 1.5—Framework, W3CCandidate Recommendation, Oct 2007

15. OASIS (2006) Web Services Security: SOAP Message Security1.1 (WS-Security 2004), OASIS Standard Specification, Oct 2006

16. TM Forum (2005) Enhanced telecom operations map (eTOM),GB921, Release 6.0, Nov 2005

17. Apache Software Foundation (2007) Web Services Project @Apache. http://ws.apache.org, Refer Oct 2007