Day Software

Adobe aquired Day Software in 2010, aquiring both their products and people

Communiqué

Day's primary product was Communiqué (a.k.a. "CQ") with customers such as McDonald's, Avanza and Daimler

Roy Fielding

Probably the most famous geek at Day was Roy Fielding:
co-founder of the Apache HTTP Server project, former chair and board member of the ASF, and "inventor" of REST

He was Day's Chief Scientist and became Principal Scientist at Adobe

Basic Server Architecture

Content Progression

Very High Level Runtime Architecture

In other words, it's a hybrid between a filesystem and a database

Or, to put it another way:

A NoSql DB specification optimized for the kinds of things web sites do (such as large binaries and "unstructured" content)

It is very much a specification:

There are a number of implementations based on specific needs

Everything Is Content

Apache Sling

Apache Sling in a hundred words

"Apache Sling is a web framework that uses a Java Content Repository, such as Apache Jackrabbit, to store and manage content.

Sling applications use either scripts or Java servlets, selected based on simple name conventions, to process HTTP requests in a RESTful way...

... The embedded Apache Felix OSGi framework and console provide a dynamic runtime environment, where code and content bundles can be loaded, unloaded and reconfigured at runtime.

As the first web framework dedicated to JSR-170 Java Content Repositories, Sling makes it very simple to implement simple applications, while providing an enterprise-level framework for more complex applications."

(from Sling's Homepage)

Apache Sling in five bullets points

• REST based web framework
• Content-driven, using a JCR content repository
• Powered by OSGi
• Scripting inside, multiple languages (JSP, server-side javascript, Scala, etc.)
• Apache Open Source project

(from Sling's Homepage)

Official Definition

OSGi technology is the dynamic module system for Java™. The OSGi Service Platform provides functionality to Java that makes Java the premier environment for software integration and thus for development. Java provides the portability that is required to support products on many different platforms. The OSGi technology provides the standardized primitives that allow applications to be constructed from small, reusable and collaborative components. These components can be composed into an application and deployed.

The OSGi Service Platform provides the functions to change the composition dynamically on the device of a variety of networks, without requiring restarts. To minimize the coupling, as well as make these couplings managed, the OSGi technology provides a service-oriented architecture that enables these components to dynamically discover each other for collaboration. The OSGi Alliance has developed many standard component interfaces for common functions like HTTP servers, configuration, logging, security, user administration, XML and many more. Plug-compatible implementations of these components can be obtained from different vendors with different optimizations and costs. However, service interfaces can also be developed on a proprietary basis.

tl;dr

It’s a specification

(with several major implementations)

Extremely lightweight

(originally created in 1999 for embedded devices at roughly the same time as J2EE)

It's based on the JAR file format, with metadata in META-INF/MANIFEST.MF

All about Modularity

(defined in terms of "bundles" and "services")

Essentially every major Java EE application server uses OSGi "under the covers" to provide its fundimental modularity

Services use the publish/find/bind model

(usually based on interfaces, but can be much more)

Full lifecycle support for both bundles and services

(dependency injection, configuration management, etc.)

Fully dynamic

(bundles/services are expected to come and go regularly)

Sane classloaders

(no split packages, explicit version management, fast graph traversal, etc.)

Harking back to its roots, when used correctly it's extremely fast and memory-efficient

Problems

• It uses classloaders differently than "standard" Java SE/EE, so any CL tricks you or your libraries do can cause issues
• A library can not be used if it does not have the OSGi metadata
  • While most of the popular libraries have OSGi metadata in their MANIFESTs, not all do — this can lead to an annoying "rewrapping the world"
  • Fortunately there's tooling that makes this fairly easy, but requires understanding of dependecies to do it "right"
• It will show you how much you suck at modularizing your code

OSGi's Future?

Bring Out Your Dead...

Deploying large applications into a single runtime is "dead", according to the micro-service people

Java 9 is "really, for sure this time" (3rd time the charm?) getting Jigsaw

• Optimized for creating modular-and-static environments (think "custom JRE")
• Has no* support for runtime modularity, such as modules being added or reloading
• Will require defining module metadata, so developers will be "forced" to finally think about it
  • Because OSGi is almost entirely a functional superset, tooling will likely appear to jump-start OSGi metadata with the Jigsaw data

Visitor ID Service

• The glue that allows the advanced features to work together
• Common identifier across our TWC sites

Audience Manager

Think of it as a database of all the traits that we know about the cookie

• First party data (web site activity, billing system)
• Third party data (data brokers)

Then create segments – collections of the visitor ids

Segments the cookie belongs to are returned from Audience Manager in a callback on page load

References

• Adobe's CQ Product Homepage
• Apache Jackrabbit JCR implementation
• Apache Sling
• Apache Felix OSGi Container