october 2009 - news from jboss world 09

News from

Andrea LeonciniJBoss Solution Architect

October 12, 2009

Andrea Leoncini News from JBoss World

Agenda

Annunci REST Infinispan HornetQ


Tre annuncidurante la manifestazione

L'uscita della versione 5 Enterprise La certificazione JBoss Administrator Il progetto GateIn


Other interesting stuff

Accelerate your JBoss – Andy Miller JBoss and all of its OSGi flavours – Alex Justin Large Clusters in JBoss – Bela Ban Extending JOPR – Heiko W. Rupp Writing Telco Applications with JBCP – Jean Deruelle JBoss 6 – Jason T. Green JBPM explained – Tom Baeyens Beyond Rails with TorqueBox – Bob Mc Whirter ...and much more

http://www.redhat.com/promo/summit/2009/highlights/


What is REST?

REpresentational State Transfer

● PhD by Roy Fielding

REST answers the questions of

● Why is the Web so prevalent and ubiquitous?

● What makes the Web scale?

● How can I apply the architecture of the web to my applications?


What is REST?

REST is a set of architectural principles

REST isn’t protocol specific

● But, usually REST == REST + HTTP

A different way to look at writing Web Services

● Many say it’s the anti-WS-*


What is REST?

Addressable Resources

● Every “thing” should have a URI

Constrained interface● Use the standard methods of the protocol● HTTP: GET, POST, PUT, DELETE, etc.

Representation Oriented

Communicate statelessly

● Stateless application scale


What is REST?

Use URIs

● Every endpoint/thing has a URI

Linkability● Resource representations have a standardized way of

referencing other resource representations● Representations have a standardized way to compose

themselves:


REST Linkability

<order id=“111”> <customer>http://sales.com/customers/32133</customer> <order-entries> <order-entry> <quantity>5</quantity> <product>http://sales.com/products/7811</product>…

<order id=“111”> <customer>32133</customer> <order-entries> <order-entry> <quantity>5</quantity> <product>7811</product>…


Constrained, Uniform Interface

The idea is to have a well-defined, fixed, finite set of operations

Resources can only use these operations

Each operation has well-defined, explicit behavior

In HTTP land, these methods are GET, POST, PUT, DELETE

How can we build applications with only 4+ methods?

SQL only has 4 operations: INSERT, UPDATE, SELECT, DELETE

JMS has a well-defined, fixed set of operations

Both are pretty powerful and useful APIs with constrained interfaces


REST in Conclusion

REST answers questions of

● Why does the Web scale?

● Why is the Web so ubiquitous?

● How can I apply the architecture of the Web to my applications?

REST is the Re-birth of HTTP

Promises

● Simplicity

● Interoperability

● Platform independence

● Change resistance


JAX-RS

JCP Specification

● Lead by Sun, Marc Hadley

● Finished in September 2008

Annotation Framework

Dispatch URI’s to specific classes and methods that can handle requests

Allows you to map HTTP requests to method invocations

IMO, a beautiful example of the power of parameter annotations

Nice URI manipulation functionality


JAX-RS Annotations

@Path

● Defines URI mappings and templates

@Produces, @Consumes

● What MIME types does the resource produce and consume

@GET, @POST, @DELETE, @PUT, @HEAD

● Identifies which HTTP method the Java method is interested in


JAX-RS Parameter Annotations @PathParam

Allows you to extract URI parameters/named URI template segments

@QueryParam

Access to specific parameter URI query string @HeaderParam

Access to a specific HTTP Header @CookieParam

Access to a specific cookie value Above annotations can automatically map HTTP request values to

String and primitive types Class types with String constructor or a static valueOf(String val)

method List or Arrays of above types when there are multiple values

@Context


JAX-RS: GET /orders/3323

@Path(“/orders”)public class OrderService {

@Path(“/{order-id}”) @GET @Produces(“application/xml”) String getOrder(@PathParam(“order-id”) int id) { … }}


JAX-RS Resource Classes

JAX-RS annotations are used on POJO classes

The default component lifecycle is per-request

● Same idea as @Stateless EJBs

● Singletons supported too

● EJB integration defined in EE 6

● Most implementations have Spring integration

Root resources identified via @Path annotation on class




Base URI path to resource




@Path(“/{order-id}”) @GET @ProduceMime(“application/xml”) String getOrder(@PathParam(“order-id”) int id) { … }}

Additional URI patternthat getOrder() method maps to





Defines a URI path segment pattern





HTTP method Java getOrder() maps to





What’s the CONTENT-TYPE returned?





Inject value of URI segment into the id Java parameter




@Path(“/{order-id : \d+}”) @GET @Produces(“application/xml”) String getOrder(@PathParam(“order-id”) int id) { … }}

Automatically convert URI string segment into an integer



JAX-RS: POST /orders


@POST @Consumes(“application/xml”) void submitOrder(String orderXml) { … }}

What CONTENT-TYPE is this method expecting from client?



@POST @Consumes(“application/xml”) void submitOrder(Order orderXml) { … }}

Un-annotated parameters assumed to be incoming message body.

There can be only one!

JAX-RS: POST /orders


JAX-RS Implementations

JBoss RESTEasy http://jboss.org/resteasyhttp://jboss.org/resteasy Embeddable Spring and EJB integration Client Framework Asynchronous HTTP abstractions

Jersey Sun reference implementation WADL support

Apache CXF RESTLet

http://jboss.org/resteasy


References

Links

http://jsr311.dev.java.net/


http://rest.blueoxen.net/

http://java.dzone.com/articles/intro-rest

http://architects.dzone.com/articles/putting-java-rest

Books

Coming this fall “RESTFul Java” by me

O’Reilly’s “RESTful Web Services”

http://oreilly.com/catalog/9780596529260/

http://jsr311.dev.java.net/



http://rest.blueoxen.net/

http://java.dzone.com/articles/intro-rest

http://architects.dzone.com/articles/putting-java-rest

http://oreilly.com/catalog/9780596529260/


Infinispan


Cloud Computing

Clouds are happening You cannot escape them! ;) Traditional datacenters will be marginalized to niche

deployments Clouds become mainstream


Why are clouds popular?

● Piecemeal cost● Pay for what you use

● Massive, global data centers means high availability, instant backups

● Everyone benefits from economies of scale

● Ability to scale on demand

● Very fast provisioning

● Proven charging model● Remember timesharing on mainframes?


Data Storage

● Clouds are inherently stateless and ephemeral

● Databases on clouds don't make sense● Traditional modes of data storage won't work

● Scalability is crucial

● Databases still are a bottleneck● … and single point of failure!


Trying to make databases work in the cloud

● Native database clustering

● Notoriously slow and non-scalable● Unreliable● Expensive!● Need special hardware, e.g., SAN


The solution: Data Grids!

● Data grids are perfect for clouds

● Highly scalable● No single point of failure● Works with ephemeral nodes● Very low latency

● Data grids● Amazon SimpleDB uses Dynamo● Infinispan, etc.● Many other commercial and open source offerings


Introducing Infinispan

● Highly scalable data grid platform● 100% open source licensed (LGPL) ● Based on some JBoss Cache code

● But mostly all-new!● JBoss Cache is a clustered caching library

● Infinispan is a data grid platform

● JBoss Cache uses a tree-structured API● Infinispan is a Map. Like JSR-107’s JCACHE


Infinispan != JBoss Cache 4

● Internal data container design completely different

● APIs completely different

● Not backward-compatible

● Although an code-level compatibility layer is available


More scalable than JBoss Cache

● Internal structures more memory efficient● Data organised in Map-like structures

● Making use of CAS● minimising synchronized blocks, mutexes

● Containers are naturally ordered● Makes eviction much more efficient

● Uses JBoss Marshalling ● Smaller payloads + poolable streams = faster remote

calls


“Borrowed” from JBoss Cache

● JTA transactions● Replicated data structure● Eviction, cache persistence● Notifications and eventing API● JMX reporting● Fine-grained replication● MVCC locking● Non-blocking state transfer techniques● Query API● Custom (non-JDK) marshalling


… and new features!

● Consistent hash based data distribution● Much simpler Map API (JSR-107 compliant)● JPA API● Client/server module with memcached

compatibility● REST API● Ability to be consumed by non-JVM platforms● JOPR based GUI management console● Distributed executors

● Map/reduce programming model made easy!


Distributed Cache

● Consistent hash based data distribution● Will allow us to scale to bigger clusters● Goal of efficient scaling to 1000’s of nodes

● Lightweight, “L1” cache for efficient reads● On writes, “L1” gets invalidated

● Dynamic rebalancing


H

HornetQ is the new name for JBoss Messaging 2 HornetQ is an open source community project to build a

multi-protocol asynchronous messaging system HornetQ is designed for performance HornetQ is designed with usability in mind HornetQ is full featured See the wiki for more information:

http://www.jboss.org/community/wiki/HornetQGeneralFAQs

jboss.org/hornetqjboss.org/hornetq

http://www.jboss.org/community/wiki/HornetQGeneralFAQs


How does HornetQ relate toJBoss Messaging?

We decided to rename JBoss Messaging 2 to HornetQ JBM 1.x and 2.x code bases 95%+ different. HornetQ is a different beast to JBM 1.x HornetQ is not tightly coupled to JBoss Application

Server


Both standalone and JEE messaging

HornetQ is a fully functional stand-alone messaging server – if you don't want an app server, don't use an app server

HornetQ can also be integrated with any JEE application server, e.g. JBoss Application Server 5.0, using its JCA adaptor

HornetQ can also be used with any dependency injection framework, e.g. JBoss MC, Spring, Google Guice


HornetQ features

Very high performance journal Support for huge queues and huge messages with small

server and client footprint Pluggable transport system Seamless High Availability (HA) Massively flexible clustering Extensive management API Lots, lots, more, but no time here! See the wiki for a full

list:http://www.jboss.org/community/wiki/HornetQFeatures

http://www.jboss.org/community/wiki/HornetQFeatures


Ultra high performance journal

HornetQ persistence is very fast Very fast store using Linux asynchronous IO. Up to 100+ MiB/s on a single node! JNI interface to aio library (libaio), encapsulated in

Java package. Automatic switches to Java NIO when not running

on Linux


Huge queues and messages

HornetQ supports huge queues – far bigger than can fit in available RAM

Run Terabyte queues while the server is only running in 50MiB of RAM!

Send and receive huge multi-gigabyte messages with all the normal transactional semantics

Effectively, only limit to message size is available disk space. We have tested messages up to 8 GiB in size.


Configurable Transport system

Fully pluggable transport Ships with default implementation using JBoss Netty

http://jboss.org/netty/ TCP transport SSL transport HTTP transport Servlet transport In-VM transport

http://jboss.org/netty/

News from

Grazie!

[email protected]

october 2009 - news from jboss world 09

Technology

jboss world

jboss andy miller jboss

class andrea leoncininews

context andrea leoncininews

jboss bela ban

pathparamorderid int

rest linkability

jbcp jean deruelle jboss