+ All Categories
Home > Documents > Java onebrazil hk2

Java onebrazil hk2

Date post: 05-Dec-2014
Category:
Upload: jerome-dochez
View: 925 times
Download: 9 times
Share this document with a friend
Description:
 
42
<Insert Picture Here> HK2, GlassFish, WLS and beyond Jerome Dochez GlassFish Architect
Transcript
Page 1: Java onebrazil hk2

<Insert Picture Here>

HK2, GlassFish, WLS and beyond

Jerome DochezGlassFish Architect

Page 2: Java onebrazil hk2

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.

Page 3: Java onebrazil hk2

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

Page 4: Java onebrazil hk2

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

Page 5: Java onebrazil hk2

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

Page 6: Java onebrazil hk2

6

JDK 6

OSGi runtime

HK2

GlassFish V3

Felix, EquinoxBindings

Static Binding

GlassFish V3 Runtime

Page 7: Java onebrazil hk2

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

Page 8: Java onebrazil hk2

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.

Page 9: Java onebrazil hk2

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

Page 10: Java onebrazil hk2

10

JDK 6

GlassFish

Felix, EquinoxBindings

Iteration one of integration

GlassFish and WLS Clients WLS Server

OSGi Runtime

Static Binding

HK2

Page 11: Java onebrazil hk2

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

Page 12: Java onebrazil hk2

12

Example

Contract Definition@Contractpublic interface SomeContract {void someMethod();

}

Service implementation @Service

public class SomeService implements SomeContract {..}

POJO implements POJI

Page 13: Java onebrazil hk2

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();

Page 14: Java onebrazil hk2

14

•By Contract@Inject AnInterface aInterface;

•By Name & Contract@Inject(name=“foo”) AnInterface anInterface;

•By Type@Inject AnImplementation aImpl;

“Flavors” of D.I.

Page 15: Java onebrazil hk2

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); }

Page 16: Java onebrazil hk2

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.

Page 17: Java onebrazil hk2

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).

Page 18: Java onebrazil hk2

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.

Page 19: Java onebrazil hk2

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

Page 20: Java onebrazil hk2

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.

Page 21: Java onebrazil hk2

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>

Page 22: Java onebrazil hk2

22

Configuration extensibility

@Configuredinterface Server extends … { @Element(“*”) public List<Module> modules}

@Configured interface RailsModule extends Module { @Attribute String name();}

@Configuredpublic interface WebModule extends Module {...}

Page 23: Java onebrazil hk2

23

Configuration Extensibility (2)

<server> <rails-module name=”foo”/> <rails-module name=”bar”/> <web-module name=”xyz”/></server>

Page 24: Java onebrazil hk2

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.

Page 25: Java onebrazil hk2

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.

Page 26: Java onebrazil hk2

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).

Page 27: Java onebrazil hk2

27

Hk2Runner – JUnit Integration

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

Page 28: Java onebrazil hk2

28

Hk2 Microkernel Beyond GlassFishHow and why WebLogic Server is converging

on Hk2.

Page 29: Java onebrazil hk2

29

WLS Convergence on Hk2

•WebLogic Server• High-end, enterprise features• Very mature product (circa 1998)• Established design• Complex interdependencies between infrastructure components

Page 30: Java onebrazil hk2

30

Snapshot of some of thestartup services

XMLService

MessageInterceptionService

MigratableRMIService

EditAccessService

CompatibilityMBeanServerService

HealthMonitorService

MigratableServerServiceImpl

MigrationService

T3InitializationService

T3BindableService

CSharpInitializationService

ChannelRuntimeService

TransactionRecoveryFailBackService

TransactionRecoveryNoOpService

DefaultStoreService

TransactionService

JDBCService

StoreDeploymentService

CustomResourceServerService

CacheProviderServerService

EJBContainerService

J2EEConnectorService

ConfiguratorService

JMSService

DeploymentShutdownService

ApplicationShutdownService

AppClientDeploymentService

FileService

TimerService

HeartbeatHelperService

Page 31: Java onebrazil hk2

31

Startup Services (cont)BridgeService

SAFService

ServletContainerService

ConversationService

WTCServerLifeCycleService

WebServicesService

WSATTransactionService

RuntimeServerService

EditServerService

DomainRuntimeService

HarvesterService

ClassDeploymentService

ServerLifeCycleService

EnableAdminListenersService

ConfigImageSourceService

PathService

SNMPAgentDeploymentService

DeploymentRegistrationService

PersistenceRegistrationService

RegistrationService

ValidationService

DeploymentPreStandbyServerService

Page 32: Java onebrazil hk2

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...

Page 33: Java onebrazil hk2

33

WLS Lifecycle

Page 34: Java onebrazil hk2

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

Page 35: Java onebrazil hk2

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…

Page 36: Java onebrazil hk2

36

New Features in Hk2

•The RunLevelService

•Habitat Listeners & Trackers

•Hk2Runner

•...

Page 37: Java onebrazil hk2

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.

Page 38: Java onebrazil hk2

38

The RunLevelService (cont)

@Contractpublic interface RunLevelService<T> { ...

/** * Causes this RunLevelService to move to * the specified run level … */ void proceedTo(int runLevel);}

Page 39: Java onebrazil hk2

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

Page 40: Java onebrazil hk2

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

Page 41: Java onebrazil hk2

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

Page 42: Java onebrazil hk2

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


Recommended