OSGi Community Event 2017 Keynote Q&A


Tickets Schedule Conference Hotels Sponsors  Questions?

Emanoel Xavier (Intel) and co-presenter Tim Ward (Paremus) to deliver the OSGi Keynote address for 2017

Join them to explore their “Journey from Monolith to a Modularized Application: Approach and Key Learnings” on Wednesday, October 25, in Ludwigsburg, Germany, at the OSGi Community Event.

The keynote examines the motivations, experience and lessons of modularizing a monolith application, which is now available as the open source Open Security Controller. The OSGi Alliance is pleased to have caught up with them both for a Q&A to get some more details on the upcoming keynote. Thanks to Emanoel and Tim for their contributions below.

Emanoel Xavier Q&A

Emanoel Xavier is a senior software developer in the Intel Platform Security Division. Responsible for developing security solutions for cloud and data center infrastructures based on software defined networks (SDN) and virtualization technologies such as OpenStack and Kubernetes. As one of the development leads on the modularisation of Open Security Controller (OSC) Emanoel is ideally placed to share the project experiences of the migration to OSGi. Prior to Intel, Emanoel worked for Microsoft, enabling billing, payments and retail SaaS solutions on the cloud with focus on identity and authentication, making the best use of protocols like OAuth and OpenId. During the course of his career he was also dedicated to the quality aspects of his projects, defining feature, functional and unit test approaches for various services and applications.

 

OSGi AllianceWhat is Open Security Controller?
Emanoel Xavier: Open Security Controller Project is a software-defined security orchestration solution that automates deployment of virtualized network security functions like next-generation firewall, intrusion prevention systems and application data controllers. The Open Security Controller Project integrates with SDN solutions to enable East-West data center security, is scalable and reduces threats in software defined network environments.OSC simplifies and automates security management and compliance and, because it is open, offers organizations the flexibility to choose the security technology that is best suited to their needs.

Alliance: Who is involved in the Open Security Controller project?
Xavier: The current members involved with the project are Huawei, Intel, McAfee, Nuage Networks and Palo Alto Networks. The Open Security Controller Project is an open source project of The Linux Foundation. You can find the up-to-date list of members at https://www.opensecuritycontroller.org/members/.

Alliance: Please provide some history to OSC and what your and Intel’s role in the OSC project is.
Xavier: OSC was a closed source software project developed within Intel to simplify the usage and adoption of network security solutions. As we realized that the benefits of OSC as a security orchestrator could be applied across different security providers and cloud environments we identified the need to make the OSC architecture extendable and ISV agnostic.  Beyond adding extension points to the product, we also identified an opportunity to build an open community around the project. Our team at Intel has worked over the past year in collaboration with the early community on making OSC ready for its open source release, which happened in June 2017.

Alliance: What prompted the timing of the migration from a monolith to a modular project? What new or developing issue(s) was the pressure point for the project? 
Xavier: Prior to modularizing the OSC core components, the project already had two other distinctive modules: its security manager and SDN controller plugins. Our first goal was to make these components truly isolated, allowing for co-habitability of plugins without dependency leaks. This was the first place where OSGi was adopted in OSC. Beyond that, we understood that having a monolithic core would make the code maintainability, testability and extensibility a lot harder. Because we believe these tenets are highly important for any healthy open source project, we decided that breaking that monolith into well-defined modules was truly the way to go, and this was another area where we benefited from using OSGi.

AllianceWhy did you choose OSGi over other options to implement your project goals?
Xavier: Another option we considered was to define the contract between OSC and those external services through REST APIs. This would mean the ISVs implementing security managers and SDN controller services would need to expose an endpoint compatible with OSC. The drawback of this approach as opposed to the plugin model is the higher cost of building and maintaining such endpoints. The plugin model represents a much quicker and light weight way to integrate with OSC, and OSGi supports this model by providing mechanisms to isolate the plugin implementation and their dependencies.

AllianceDo users of OSC need to use or know OSGi in order to benefit?
Xavier: OSGi knowledge is not needed by security administrators using OSC to orchestrate security functions. Developers creating new plugins for OSC would benefit from basic OSGi knowledge, however, this is not a requirement.


Tim Ward Q&A

Tim Ward is CTO at Paremus Ltd, a co-author of Enterprise OSGi in Action, and has been actively working with OSGi for the last decade.

In the OSGi Alliance Tim has been a regular participant in the OSGi Core Platform and Enterprise Expert Groups, and is co-chair of the OSGi IoT Expert Group. Tim has led development of several specifications within OSGi.Tim is also an active Open Source committer, he contributes regularly to the Bndtools project and is a PMC member in the Apache Aries project.

 

Alliance: What is/was your role in the migration to OSGi?
Tim Ward: I was the lead consultant from Paremus for several phases of the Open Security Controller modularization engagement. I was responsible for technical liaison with the Intel team, and leading and managing a small Paremus team to deliver the migration of the Open Security Controller project to OSGi. The Paremus roles included:

  • Identifying opportunities for modularity to make the Open Security Controller simpler and more robust.
  • Creating high-level designs outlining the steps required to modularize parts of the OSC codebase.
  • Implementation work, focusing on areas where the Intel team agreed that Paremus’ OSGi experience could best accelerate delivery.
  • Providing training, oversight and advice for the Intel team as they continued to deliver functionality throughout the project.

Alliance: How does the OSC project demonstrate the classic OSGi value proposition for modularity?
Ward: When Paremus were first engaged to help with the OSC project it was a typical Java SE service application, offering a JAX-RS REST interface and a JavaScript Web UI. The project used a Maven build, and was split into a number of separate build components divided broadly by function. These components indicated an intended modularity, however there were still a number of maintainability issues that needed to be addressed:

  • The OSC application was initially intended to be developed by a single team integrating and testing the application as a whole. This model needed to change to allow third party security services to write their plugins independently and then integrate with the OSC application at runtime.
  • The original model provided no isolation for third party plugins from the core server runtime, meaning that libraries could easily conflict between plugins, and also with the server.
  • Despite the notional separation by function, there was still significant coupling between the various build components, with improper use of static methods and insufficiently well defined internal APIs.  This degree of static coupling made unit testing some components particularly challenging.

Moving to OSGi has ensured that the intended modularity of the OSC codebase is actually enforced at runtime. This, in turn, surfaced unexpected links and dependencies. The adoption of proper module APIs and independently built components decoupled the various modules, reducing the complexity of the build, and speeding up the development cycle. This also allowed for easier testing, and provided a much stronger guarantee that internal changes would not ripple out to affect other components. Additionally the dynamic nature of OSGi simplified the startup of the OSC application, allowing for much of the lifecycle code to be eliminated entirely.

Combined with the new Maven build support in the recent Bndtools 3.4.0 release, Intel OSC is are now able to take advantage of state of the art OSGi development tooling to accelerate their product delivery.


Thanks To Our Sponsors
Elite Dual ECE / OSGi CE Sponsor