Is There A Cookie Cutter Pattern Behind OSS/J and MTOSI?

Creating a Stable OSS Application Foundation

OSS standardization is the tedious and time-consuming task of getting the industry to agree on common interfaces and practices.

Over the years, the TM Forum has done great work in this area, nurturing many reference and information models such as the eTOM, SID, and the NGOSS technology neutral architecture.

However, it's a leap to go from a model to implementing software in a real network, and many architectural and programming problems need to be solved that the models don't tell you anything about. Designers, for example, need to agree on design patterns for doing all sorts of things, such as communicating with a management entity.

Now, dozens of OSS software companies are in the market today so the job is obviously getting done. Yet a key problem remains: developers tend to use home-grown, less-than-optimal methodologies, and when the underlying technology plates shift, say, from Java/EJB to Web Services, those designs collapse and need to be rebuilt from scratch.

So wouldn't it be nice if some agreed design patterns were available to give OSS applications a stable, forward-looking foundation?

Well, that's the intent of new book called "OSS Design Patterns" published by Springer and written by two veterans of OSS standardization and development, Colin Ashford and Pierre Gauthier, both Nortel alumni.

Recently I caught up with Colin at the TM Forum's Management World in Orlando:

The Scope and Complexity of OSS Applications

Dan Baker: What prompted you to write a book on OSS design patterns?

Colin Ashford: Well, the idea goes back to our days at Nortel where we saw veteran designers use elegant and repeatable techniques for solving OSS software problems. Novice designers, by contrast, were usually overwhelmed by the options available and often designed inefficient solutions.

So the goal of our book is to bring some of that veteran design expertise to the table and help developers who deploy management solutions - for anything from existing technologies like DSL to cutting-edge stuff like LTE.

The scope and complexity of OSS applications has brought with it many technology shifts. When I first got involved in OSS development, OSI Network Management was seen as the way forward, then the industry went to SNMP, then it went to CORBA, and that was closely followed by Java, then XML, and now Web Services. Well, these are very different implementation technologies and that entails redoing the software implementations.

The thesis of our book is that no matter what the implementation technology is, you can develop a pattern of thinking about OSS problems that greatly simplifies that implementation.

Interfacing to the Technology of the Day

TRI: But the TM Forum has developed interface specifications such as MTOSI and OSS/J that guide the developer, right?

CA: This is true, but each was independently designed and implemented using the technology du jour, and the differences in underlying operational models and data models makes integration of those OSS applications into a unified management solution much harder.

So how do you help a designer develop the elegant and reusable OSS interfaces you talk about?

Well, first we propose a five-layer OSS Reference Model - similar in style to the OSI Reference Model. Each layer is responsible for a functional aspect of the whole system - operator-task workflow, application integration, adaption to real resources and so on. The purpose of the reference model is to allow the designer to reason about each part of the problem at hand without getting bogged down in implementation details.

From Reference Model to Software Design Guide

TRI: Then how do we get from the Reference Model to something that guides the software design?

CA: We have to map the various functional layers into a reference architecture using a particular architectural style-in our case a client-server style. The OSS Reference Architecture embodies that mapping and sets the architectural direction for the design of the interfaces to the OSS applications.

The OSS Reference Architecture defines an interface, the OSS Integration Interface, between an OSS client (typically a network operator's workstation) and an OSS application (say a trouble-ticket application). The patterns we propose in our book model the resources to be managed (e.g. trouble tickets), the operations that can be invoked on those resources (e.g. update a trouble ticket), and the data that flows across the interface (e.g. the updated status of the trouble ticket).

TRI: Can software designers lift the code to implement OSS interfaces from your book?

CA: Yes and no. The essence of a pattern is that the description is implementation-technology neutral (we use narrative and UML to describe our patterns). However, to demonstrate that our patterns are implementable, we give code examples in Java, XML/JMS and Web Services - and the code really runs, believe me. And we are convinced that our patterns are backwards compatible to technologies such as CORBA and forwards compatible to technologies such as Service Oriented Architectures.

TRI: Finally, Colin, does the industry have to adopt your patterns or can individual developers run with what you've got in book?

CA: I think the robustness and simplicity of these patterns will benefit individual OSS development teams, regardless of whether those patterns should someday be adopted as an industry agreement.

About Colin Ashford and Pierre Gauthier

Colin Ashford is the owner of the independent consulting company OSS Evolution. Colin is a professional engineer with over twenty-five years experience in the computing and telecommunications industry, primarily concerned with the standardization of distributed systems and telecommunications networks. He has held senior positions in Nortel with responsibilities for international standards and project management. Colin has been an invited speaker at TMF and ECOOP conferences, and is an OSS Through Java Fellow. He holds a master’s degree in Computer Science from Carleton University, Ottawa, Canada.

Pierre Gauthier is the owner of the independent consulting company OSSWave. For the last decade Pierre has been involved in the design and development of software for telecommunications and Operation Support Systems (OSSs), holding senior positions with Oracle and Nortel. Pierre was the driving force behind the development of the OSS/J Design Guidelines and is Spec Lead for JSR 91, the OSS Trouble Ticket API. Pierre is a JavaOne alumnus, TMF invited speaker, and JCP Star Spec Lead. He holds a master’s degree in Electrical Engineering from the Ecole Polytechnique, Montreal, Canada.