1. <Insert Picture
Here>
HK2, GlassFish, WLS and beyond
Jerome Dochez
GlassFish Architect

2. The following is intended to outline our general
product direction. It is intended for information
purposes only, and may not be incorporated into any
contract. It is not a commitment to deliver any
material, code, or functionality, and should not be
relied upon in making purchasing decisions.
The development, release, and timing of any features
or functionality described for Oracle’s products
remains at the sole discretion of Oracle.
2

3. Current State of affairs
GlassFish
–V3 released December 2009
• Java EE 6 support
• Modular application server based on OSGi
• Support for some OSGi RFCs.
• Developer focused release (fast startup,
iterative deployment features)
–V3.1 work in progress
• Adding cluster support
• Adding session replication support
• Finishing OSGi RFCs implementation
3

4. Current State of affairs
WebLogic Server
–10.3.3 released May 2010
• JRockit Flight Recorder
• Coherence Integration
• SCA, New security plugins, ...
–10.3.4 ~ CY '10
• Exalogic / Middleware Machine
• RAC Datasources
• Build Env / Developer Experience – Maven, etc.
–CY '11/'12
• Next Fusion Middleware
• EE6 (Profiles)
• Hk2 Integration / Microkernel convergence
4

5. What is HK2
HK2 is a separate open source project to help
build modular server side software.
–Used to build GlassFish V3
–Provide an abstraction to a module subsystem like an
OSGi runtime
• Bindings to Felix, Equinox and Knopplerfish
• Can be used in static mode, with no module
subsystem
–Provide a simple yet powerful dependency injection
• No XML
• Purely annotation based
• Lazy instantiation/resolution
5

6. GlassFish V3 Runtime
GlassFish V3
HK2
Felix, Equinox
Bindings
Static
Binding
OSGi runtime
JDK 6
6

7. Shared Architecture Vision
• No OSGi dependency in code
– e.g Embedded GlassFish does not require OSGi.
– Simplified programming model
– Fixed some OSGi design patterns not applicable to server side
software :
• Focus on dynamic modules (ability to load/unload modules at
runtime)
• Lazy loading/resolving rather than Activator/Extender patterns
that often require immediate resolution of modules
• Modules are not off the shelves components
7

8. GlassFish distinctions
• Modules are created to support GlassFish
use cases
• Fast startup : move away code that we don't
necessarily need on startup.
• Container isolation : ability to create distributions
with various capabilities (no EJB container or no
Web container).
• Extensibility : ability to add or remove entire set of
components in an installed image.
• Code relationships based on Services.
8

9. HK2 and WLS
• WLS and GlassFish are both Java EE
application servers offered by Oracle
• So where does it intersects ?
• WLS 12c is targeted to support :
• Java EE 6 platform specifications
• Java EE profiles...
• HK2 micro-kernel
• Dependency Injection
• RunLevelService
9

10. Iteration one of integration
GlassFish and
GlassFish WLS Server
WLS Clients
HK2
Felix, Equinox
Bindings Static
Binding
OSGi Runtime
JDK 6
10

11. HK2 Features
• Abstraction to the module subsystem
• Service Based Architecture
• Services can be looked up or injected
• Services annotated with @Service implements
interfaces annotated with @Contract
• Disambiguate using name
• With scopes (singleton, per lookup, per thread)
• Configuration handling
• Binding to XML files
• Transactional access
• Support Validation APIs and MBeans/REST
11

12. Example
Contract Definition
@Contract
public interface SomeContract {
void someMethod();
}
POJO
implements POJI
Service implementation
@Service
public class SomeService implements SomeContract {..}
12

13. Dependency Injection
•Service implementation
@Service
public class Simple implements SomeContract {
public void someMethod() {..}
}
•Simple client
@Service
public class AnotherManagedService {
@Inject
SomeContract svc;
...
svc.someMethod();
13

14. “Flavors” of D.I.
•By Contract
@Inject AnInterface aInterface;
•By Name & Contract
@Inject(name=“foo”) AnInterface anInterface;
•By Type
@Inject AnImplementation aImpl;
14

15. Service Based Runtime
• Contracts implementations annotated with
@Service
• Optional name
• Scope (singleton, perLookup, threaded)
• No scope annotation = singleton
• Habitat contains all the services
List<Startup> list = habitat.getAllByContract
(Startup.class);
• Current GlassFish startup code (simplified)
for (Startup s : habitat.getAllByContract(Startup.class)) {
Logger.info(“Started “ + s);
}
15

16. Component
• Services are components, with a scope
(lifecycle), have dependencies providing
contracts implementation
• Dependencies are expressed with
@Inject
• Injected resources can be resources
themselves
• Service allocation cascading based on D.I.
• Injected resources are looked up from the
habitat.
16

17. Server Initialization
• On startup, hk2-jars are introspected :
• List of available contracts (indexes)
• List of services implementing such contracts.
• Lazy lookup of services.
• No class-loader is created until a service is
actually requested!
• Experimenting with ASM to be able to use
normal jar rather than enforcing hk2-jar
(presence of the inhabitant file is mandatory
so far).
17

18. Component Lifecycle
• PostContruct
–Interface implemented to have a postConstruct
method called after injection is performed.
–Constructor cannot be intercepted.
–After postConstruct is called, service is installed in the
habitat.
• PreDestroy
–Interface called when service is removed from the
habitat.
–Hook for cleanup.
18

19. Tricks to remember
• Nobody calls services any more, they call
contracts implementation.
• Services are dynamic, remove an optional
jar from the modules directory and its
services are not available.
• Services use injection to get initialized, very
little explicit lookup.
• Services initialization will result in multiple
sub services cascade initialization :
• No multi-threading
• No circular references support
19

20. GlassFish approach to Config
• Special type of components to read/write
configuration data to the domain.xml
• Mapping defined via interfaces (kind of like
JAXB)
• Interfaces are annotated with @Configured
annotation
• Fields are annotated with @Attribute
• Sub-elements are annotated with @Element
• Supports subclassing and extensibility
• Configuration mapping for WLS not finalized
yet.
20

21. Configuration Example
@Configured public interface Server extends …
{
@Attribute(key=true) String name();
@Attribute String description();
@Element Replication replication;
}
@Configured
public interface Replication extends ... {...}
<server name=”foo” description=”some server”>
<replication .../>
</server>
21

22. Configuration extensibility
@Configured
interface Server extends … {
@Element(“*”)
public List<Module> modules
}
@Configured
interface RailsModule extends Module {
@Attribute String name();
}
@Configured
public interface WebModule extends Module
{...}
22

23. Configuration Extensibility (2)
<server>
<rails-module name=”foo”/>
<rails-module name=”bar”/>
<web-module name=”xyz”/>
</server>
23

24. Configuration implementation
• Based on streaming parser
• One class implements all @Configured
interface (Dom.java)
• Each instance of Dom creates a proxy view
of the data, the proxy type is the
@Configured annotated type.
• User's code use interface based access, all
configuration data is stored in a network of
Dom instances.
24

25. Transactions
• Simple transactions must be started to change
configuration objects.
• Mutated object must be identified to the tx.
• Concurrent transactions can happen as long as
they don't mutate the same config instances.
• Transaction are either committed or rollbacked.
• Committed transaction are written to the
domain.xml and listeners are notified
• Transactions can be rejected by the system.
• Some transactions require restart of server.
25

26. wait ! there is more
• Bean Validation
• Mbeans
–All configured interfaces instances can be
automatically registered in the mbean server.
• Generic admin commands
–CRUD style commands with no extra code.
• REST
–All configured interfaces instances available through
REST interface
–@RestRedirect when rest commands trigger a
command invocation rather than just changing the
configuration (e.g. deploy).
26

27. Hk2Runner – JUnit Integration
@RunWith(Hk2Runner.class)
public class RunLevelServiceTest {
@Inject
Habitat h;
@Inject(name="default")
RunLevelService<?> rls;
@Test
void testSomething() {...};
27

28. Hk2 Microkernel
Beyond GlassFish
How and why WebLogic Server is converging
on Hk2.
28

29. WLS Convergence on Hk2
•WebLogic Server
• High-end, enterprise features
• Very mature product (circa 1998)
• Established design
• Complex interdependencies between infrastructure
components
29

30. Snapshot of some of the
startup services
XMLService TransactionService
MessageInterceptionService JDBCService
MigratableRMIService StoreDeploymentService
EditAccessService CustomResourceServerService
CompatibilityMBeanServerService CacheProviderServerService
HealthMonitorService EJBContainerService
MigratableServerServiceImpl J2EEConnectorService
MigrationService ConfiguratorService
T3InitializationService JMSService
T3BindableService DeploymentShutdownService
CSharpInitializationService ApplicationShutdownService
ChannelRuntimeService AppClientDeploymentService
TransactionRecoveryFailBackService FileService
TransactionRecoveryNoOpService TimerService
DefaultStoreService HeartbeatHelperService
30

31. Startup Services (cont)
BridgeService DeploymentRegistrationService
SAFService PersistenceRegistrationService
ServletContainerService
RegistrationService
ConversationService
ValidationService
WTCServerLifeCycleService
DeploymentPreStandbyServerService
WebServicesService
…
WSATTransactionService
RuntimeServerService
EditServerService
DomainRuntimeService
HarvesterService
ClassDeploymentService
ServerLifeCycleService
EnableAdminListenersService
ConfigImageSourceService
PathService
SNMPAgentDeploymentService
31

32. Complex Interdependencies
• Each of the services can represent a
subsystem
• Each of the services require lifecycle
• Ordering of startup / shutdown is important
–Previously used an ordinal numbering scheme, but
that was problematic.
–Each of the services on the previous diagram are
now annotated with a “RunLevel” phase...
32

33. WLS Lifecycle
33

34. Motivation
• The Obvious (I.e., we wanted / needed a
microkernel)
• Model dependencies & lifecycle controls (internal motivation)
• Service-oriented approach (internal motivation)
• IoC / DI mechanism included (internal motivation)
• More flexibility in profile creation (external and internal
motivations)
• DM vs HK2
• Hk2 / GlassFish was out there in customer’s hands!
• Hk2 abstracted the underlying module system whereas DM
assumed OSGi
• Hk2’s fast start-up and on-demand loading impressed
34

35. Notable…
• No “rewrites”
• No restarts
• Currently working out config details
• No change to the way JVMs are started
• Server is “primed” at startup, no 1st request
delays
• Desire to blend best of breed components
=> Hk2 would need to support new features
for WLS…
35

36. New Features in Hk2
• The RunLevelService
• Habitat Listeners & Trackers
• Hk2Runner
• ...
36

37. The RunLevelService
• An annotation based approach for dealing
with service start levels integrated into the
DI machinery
• One default RunLevelService instance for
the “platform”.
• extensible for any one else to extend or use for
subcomponent lifecycle processing.
• “Creates demand” for services (I.e., Eager
initialization).
• The default is lazy and not something the WLS PM's
said they wanted.
37

38. The RunLevelService (cont)
@Contract
public interface RunLevelService<T> {
...
/**
* Causes this RunLevelService to move to
* the specified run level …
*/
void proceedTo(int runLevel);
}
38

39. The RunLevelService (cont)
• The @Admin Meta Annotation
@Retention(RUNTIME)
@Target(TYPE)
@org.jvnet.hk2.annotations.RunLevel(value=ServerStates.SRVR_ADMIN)
public @interface Admin {}
• Each WLS meta annotation correlates to
existing ServerStates
• @Immediate
• @Starting
• @Running
• @StandBy
39

40. Example ServerService – Boot Service
@Starting
@Service (name=ServerServiceTags.KERNEL)
public class BootService extends AbstractServerService {
@Inject (name=ServerServiceTags.IMAGE_MANAGER_SERVICE_NAME)
private ServerService imageManagerService;
public void start() throws ServiceFailureException
public void stop()
public void halt()
• Ordering dictated by
• Injection
• RunLevel
• Constraint Checking
40

41. Modular Server Services
• Externalize Server Profiles
• A new service is as simple as adding an annotation
• Dynamically creates the services start structure based on
the selected server profile
• Keep existing WLS outward appearance
• Outward Logging
• Current Server State and Lifecycle Changed
• Continues use of the Server Services Interface and programming
paradigms
41

42. Challenges
• Past challenges:
–Teasing out dependencies between the subsystems
(ordinal start ordering -> dependency based start
ordering).
• Future challenges:
–Parallelization of startup ServerServices (RLS)
–Dynamic & Configuration Driven Services – Hot
Rewiring
–Hk2 “omni presence” in products - N x Clients & Tools
–Visualization of the dependency graph (tooling)
–Convergence with JSR-299 / 330
42