1. AS7, Domain Models, Cloud and how can I be
on-demand?
Bruno R. Machado
Samuel Tauil

2. Agenda
What is JBoss AS7?
Standalone Topology
Domain Mode

Domain Terminology

Domain Topology

Domain configuration
Management Interfaces Topology
Domain Architecture Examples
DEMO

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

4. Cloud-ready architecture
High degree of automation
Flexible Management
Frugal use of resources
Lean, agile development
Open Platform
PHYSICAL VIRTUAL PRIVATE PUBLIC
JBOSS ENTERPRISE MIDDLEWARE

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

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

7. 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:s
ervice=TransactionManager",
exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceM
Bean.class, registerDirectly=true)</annotation>
<annotation>@org.jboss.managed.api.annotation.ManagementObject(name="Tr
ansactionManager",componentType=@org.jboss.managed.api.annotation.Manag
ementComponent(type = "MCBean", subtype =
"JTA"),targetInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerSe
rviceMBean.class)
</annotation>

8. Web Console
Simple
Fast
Lightweight
Avoids XML config
Single instance and
Domains
Mostly Configuration

9. Web Console
JBoss AS 5.x

10. Architecture

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

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

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

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

15. 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 driven
see $EAP6_HOME/docs/schema

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

17. Profiles available out-of-the-box
default
most 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
ha
default + jgroups and modcluster subsystems (cluster)
full
default + messaging subsystem (HornetQ), cmp, jacorb, jaxr,
jsr77
full-ha
full + jgroups and modcluster subsystems (cluster)

18. Standalone Topology
Only
distinction
No centralized
management
capability!

19. Domain Terminology
Host = physical or virtual machine

20. Domain Terminology
Master = Domain Controller (DC)
acts as the central management
control point for the entire domain
Slave = host in the domain
interacts with the DC to
control the JVMs’ lifecycle
according to the domain policy

21. Domain Terminology
Process controller
is started by domain to
spawn server and host
controller processes
and to manage their I/O

22. Domain Terminology
Server groups
set of server instances
that will be managed and
configured as one
Server
separate JVM process
representing an actual
Application Server

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

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

25. Domain Topology - Big Picture
25

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

27. Management interfaces topology
27

28. Domain Architecture
Examples
28
This architecture is used
in one of the biggest
Health Insurance company
of Latin America
Dedicated Domain
Controller
4GiB of Memory +
2 virtual cores
can manage ~
100 hosts +
200 server domain
Probably 1.7GiB +
1 core would be fine
running the same 100 hosts
and 200 server domain

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

30. DEMO

31. Awaiting Volunteers
Want to help us?
http://bit.ly/11FYCTh