JUDCon Brazil 2013 - Domain Models with JBoss AS 7

Post on 06-May-2015

835 views 4 download

transcript

AS7, Domain Models, Cloud and how can I be on-demand?

Bruno R. MachadoSamuel Tauil

Agenda

What is JBoss AS7?

Standalone Topology

Domain Mode Domain Terminology Domain Topology Domain configuration

Management Interfaces Topology

Domain Architecture Examples

DEMO

What is JBoss AS7?

Also known AS7 or JBoss EAP6 (enterprise version) stable, innovative and supported Platform implements the Java EE 6 Specification consisting of 2

profiles

Web profile contains the web-based technologies of Java EE:

Servlets, JSP, JSF, CDI, JPA and EJB Lite ...

Full profile contains all of the Java EE technologies

Cloud-ready architectureHigh degree of automation

Flexible Management

Frugal use of resources

Lean, agile development

Open Platform

PHYSICAL VIRTUAL PRIVATE PUBLIC

JBOSS ENTERPRISE MIDDLEWARE

New Features

New concept and new architecture completely different from previous versions

– 3.x/4.x (microkernel)

– 5.x/6.x (microcontainer)

Lightning fast! services are started on-demand and concurrently and all

non-critical services remain passive

Single configuration file all configuration details are viewed in a single file

(standalone.xml for standalone and domain.xml and host.xml for domain server)

New Features

True modularity small core with most of its features and capabilities

contained in modules application isolation with smarter class loading can be introduced and configured as needed

Lightweight style small memory footprint

Management flexibility new Command Line Interface (CLI) new user-friendly web console comprehensive Native Management API and HTTP

management API

User-focused configuration

<subsystem xmlns="urn:jboss:domain:transactions:1.0"> <recovery-environment socket-binding="txn-recovery-environment" status-socket-binding="txn-status-manager"/> <core-environment socket-binding="txn-socket-process-id"/></subsystem>

<bean name="TransactionManager" class="com.arjuna.ats.jbossatx.jta.TransactionManagerService"> <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=TransactionManager", exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class, registerDirectly=true)</annotation> <annotation>@org.jboss.managed.api.annotation.ManagementObject(name="TransactionManager",componentType=@org.jboss.managed.api.annotation.ManagementComponent(type = "MCBean", subtype = "JTA"),targetInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class) </annotation>

Web Console

Simple

Fast

Lightweight

Avoids XML config

Single instance and Domains

Mostly Configuration

Web Console

JBoss AS 5.x

Architecture

JBoss Modules

Standalone implementation of modular (non-hierachical) class loading and execution environment for JAVA

libraries packed in modules link against the exact modules they depends on, and

nothing more works with any library or application without changes makes on-demand services possible

Class loader model is ... thread-safe fast highly concurrent delegating

Module Definition - Static FS Repository

<!-- definitions are in module.xml --><module xmlns="urn:jboss:module:1.1" name="org.jboss.logging"> <resources> <resource-root path="jboss-logging-3.x.x.jar"/> </resources> <dependencies> <module name="org.jboss.logmanager"/> </dependencies></module>

<!-- definitions are in module.xml --><module xmlns="urn:jboss:module:1.1" name="org.jboss.logging"> <resources> <resource-root path="jboss-logging-3.x.x.jar"/> </resources> <dependencies> <module name="org.jboss.logmanager"/> </dependencies></module>

Class Loading

Is based on the principles of modular class loading Modules delegate to one another as peers A module imports modules it directly uses Transitive dependencies are hidden, by default Different module versions may co-exist

Every application deployment is a module

Core module libraries are implicitly provided by the Server

Other modules need to be explicitly declared in MANIFEST or custom deployment file (jboss-deployment-structure.xml)

Operating Modes

Domain Operating Mode (new)– Spawns multiple JVMs (servers) on multiple

physical / virtual machines which build up the domain

– Ability to manage multiple JVMs (servers)from a single control point

– Servers in the Domain share a common management policy

Standalone Operating Mode (Similar to JBoss AS 4/5)

Which Operating Mode fits into my Environment?

Subsystems

... are sets of capabilities added by an extension

Adding features and attributes of an extension in a server is done within <subsystem> element in the standalone and domain configuration file (as part of the <profile> configuration)

Configurations of systems are schema-file drivensee $EAP6_HOME/docs/schema

Profile

... is a set of configured subsystems

The <profile> element only allows child element <subsystem>

Standalone Mode defines only one single and unnamed profile can be used as multiplier for other standalone instances

Domain Mode can provide several profiles each profile has specific name and can be used by

server groups

Profiles available out-of-the-box

defaultmost commonly used subsystems: logging, configadmin, datasources, ee, ejb3, infinispan, mail, jaxrs, jca, jdr, jmx, jpa, mail, naming, osji, pojo, remoting, resource-adapters, sar, security, threads, transactions, web, webservices and weld

hadefault + jgroups and modcluster subsystems (cluster)

fulldefault + messaging subsystem (HornetQ), cmp, jacorb, jaxr, jsr77

full-hafull + jgroups and modcluster subsystems (cluster)

Standalone Topology

Only distinction

No centralizedmanagement capability!

Domain Terminology

Host = physical or virtual machine

Domain Terminology

Master = Domain Controller (DC)acts as the central managementcontrol point for the entire domain

Slave = host in the domaininteracts with the DC tocontrol the JVMs’ lifecycleaccording to the domain policy

Domain Terminology

Process controlleris started by domain tospawn server and hostcontroller processesand to manage their I/O

Domain Terminology

Server groupsset of server instancesthat will be managed andconfigured as one

Serverseparate JVM processrepresenting an actualApplication Server

Server Groups

... are defined in domain.xml using the <server-groups> element

<server-groups> consists of a one or more <server-group> child elements

<server-groups> <server-group name="server-group1" profile="full"> <jvm name="default"> <heap size="1303m" max-size="1303m"/> <permgen max-size="256m"/> </jvm> <socket-binding-group ref="full-sockets"/> <deployments> <deployment name="LAB123App.war" runtime- name="LAB123App.war"/> </deployments> </server-group></server-groups>

<server-groups> <server-group name="server-group1" profile="full"> <jvm name="default"> <heap size="1303m" max-size="1303m"/> <permgen max-size="256m"/> </jvm> <socket-binding-group ref="full-sockets"/> <deployments> <deployment name="LAB123App.war" runtime- name="LAB123App.war"/> </deployments> </server-group></server-groups>

Host Configuration - Servers

... are defined in the <servers> element of the configuration file of the host controller where server is going to run on

<servers> element can have one or more <server> child elements

<servers> <server name="server1" group="server-group1" auto-start="true"/> <server name="server2" group="server-group2" auto-start="false"> <socket-bindings port-offset="100"/> </server></servers>

<servers> <server name="server1" group="server-group1" auto-start="true"/> <server name="server2" group="server-group2" auto-start="false"> <socket-bindings port-offset="100"/> </server></servers>

Domain Topology - Big Picture

25

Domain - Configuration

domain controller{192.168.178.60}

host.xml<domain-controller> <local/></domain-controller>

domain.xml

host controller 1{192.168.178.61}

host.xml<domain-controller> <remote host=”192.168.178.60” port=”9999” /></domain-controller>

host controller 2{192.168.178.62}

host.xml<domain-controller> <remote host=”192.168.178.60” port=”9999” /></domain-controller>

Management interfaces topology

27

Domain ArchitectureExamples

28

This architecture is used in one of the biggest Health Insurance company of Latin AmericaDedicated Domain Controller

4GiB of Memory +2 virtual corescan manage ~100 hosts +200 server domainProbably 1.7GiB +1 core would be finerunning the same 100 hosts

and 200 server domain

Domain Architecture Examples

DC doesn't need to be up all the time.

Start DC in the first startup, and then use --backup --chached-dc

For failover, copy domain.xml and host.xml. Use the same IP of the old one

DEMO

Awaiting Volunteers

Want to help us?

http://bit.ly/11FYCTh