October 2009 - News From JBoss World 09

News from

Andrea Leoncini
JBoss Solution Architect

October 12, 2009

Agenda

 Annunci
 REST
 Infinispan
 HornetQ

Andrea Leoncini News from JBoss World

Tre annunci
durante 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>32133</customer>
<order-entries>
<order-entry>
<quantity>5</quantity>
<product>7811</product>
…

<order id=“111”>
<customer>http://sales.com/customers/32133</customer>
<order-entries>
<order-entry>
<quantity>5</quantity>
<product>http://sales.com/products/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

@GET
…
}
}



public class OrderService { Additional URI pattern
that getOrder() method maps to

@GET
@ProduceMime(“application/xml”)
…
}
}


public class OrderService { Defines a URI path segment
pattern

@GET
…
}
}



@Path(“/{order-id}”) HTTP method Java getOrder()
@GET maps to
…
}
}


What’s the CONTENT-TYPE
@Path(“/orders”) returned?

@GET
…
}
}



@GET
…
}
}

Inject value of URI segment
into the id Java parameter



@Path(“/{order-id : d+}”)
@GET
…
}
}

Automatically convert URI
string segment into an integer


JAX-RS: POST /orders

@Path(“/orders”) What CONTENT-TYPE is this
public class OrderService { method expecting from client?

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


JAX-RS: POST /orders


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

Un-annotated parameters assumed
to be incoming message body.
There can be only one!


JAX-RS Implementations

 JBoss RESTEasy
 http://jboss.org/resteasy
 Embeddable
 Spring and EJB integration
 Client Framework
 Asynchronous HTTP abstractions
 Jersey
 Sun reference implementation
 WADL support
 Apache CXF
 RESTLet


References

 Links

 http://jsr311.dev.java.net/
 http://jboss.org/resteasy
 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/


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


jboss.org/hornetq

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


How does HornetQ relate to
JBoss 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


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


News from

Grazie!

andrea.leoncini@redhat.com

October 2009 - News From JBoss World 09

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie October 2009 - News From JBoss World 09

Ähnlich wie October 2009 - News From JBoss World 09 (20)

Mehr von JBug Italy

Mehr von JBug Italy (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

October 2009 - News From JBoss World 09