JAX-RS(Jersey) Programming Model Stub Resource JAX-RS API JAX-RS API Server Side Runtime System Client side Runtime System Protocol (REST/HTTP) Transport WADL Service Client Service Endpoint Container WADL<->Java Mapping Dispatch
REST – Representational State Transfer JSR-311: JAX-RS Exposes named RESOURCES which represent DATA Resource: POJO URI path template ID Uses simple Nouns (Resources) and verbs (HTTP Methods) GET/PUT/POST/DELETE Emphasis on simple, stateless point-to-point communication over HTTP Supports multiple data formats JSON/XML/TEXT/XHTML Runtime Content Negotiation
SOAP – Simple Object Access Protocol Exposes OPERATIONS that implement/represent LOGIC Provides loose coupling for integrating diverse systems Designed for distributed computing Designed to be extensible – WS-* Standard error messaging – SOAP faults with standard Code/Subcode for error types Aligns with Enterprise Application needs and goals Supports other transport protocols than HTTP – SMTP, JMS Supports enterprise security with WS-Security Supports language neutrality Supports ACID, Atomic transactions with WS-AT Supports Reliable Messaging with WS-RM Easy governance with strong typing Broad Development Tools support
REST vs. SOAP REST Exposes RESOURCES which represent DATA Uses HTTP Verbs (GET/POST/DELETE) Emphasis on simple point-to-point communication over HTTP Supports multiple data formats Emphasizes stateless communication SOAP Exposes OPERATIONS which represent LOGIC Uses HTTP POST Emphasis on loosely coupled distributed messaging Supports only XML (and attachments) Supports stateless and stateful/conversational operations Supports asynchronous messaging Strong Typing
SOAP is better than REST! Building a client for REST can be challenging I can easily generate client-side artifacts from a WSDL I don’t want to write raw HTTP calls I don’t want to look at the HTTP response code for success/failure – I want to use my own exception types and codes Many IDE’s support SOAP development – both client and server REST only supports HTTP/HTTPS HTTP is synchronous and in order to scale I need to be able to have asynchronous messaging REST is not secure Parameters as part of the URI No support for acquiring tokens RESTful services have no contract I have a WADL that specifies URL’s but what about schemas for object definition REST is not reliable I have to handle failures with retries – no Reliable Messaging REST can’t be governed How do I know who is consuming my services without a Service Registry? How do I discover RESTful services?
Both SOAP and REST have their rightful places REST Good for: Web Services Limited bandwidth (smaller message size) Limited resources (no xml parsing required) Exposing data over the Internet Combining content from many different sources in a web browser SOAP Good for: Enterprise services High Reliability with WS-RM Transactions with WS-AT Security with WS-Security Asynchronous processing Contract-first development Stateful /conversational operations Standards support, interoperability with business applications Tooling Support
JSF 2.0 Great Blog Post: http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/#ajax Annotation-Driven Managed Bean Annotations Converter Annotations Composite Components Not required: UIComponent, Renderer, faces-config.xml Ajax support Navigation Implicit Navigation Conditional Navigation Project Stage: ‘Development’ provides more detailed error messaging (not just HTTP 500) Resource Libraries Loading ‘Libraries’ for CSS, Images, Etc
PrimeFaces – www.primefaces.org “PrimeFaces is a lightweight open source component suite for Java Server Faces 2.0 featuring 100+ rich set of JSF components” Easy to use, good looking components Multiple themes