WebLogic Developer Webcast 4: RESTful Services with JAX-RS, JQuery and JSF 2.0

  • 4,450 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
4,450
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
86
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Jersey is the reference implementation of JAX-RS and is the implementation that you will find in both WebLogic Server and GlassFish. Lets take a look at the programming model.First, if you stick with the best practices and the standard approach to REST you will create ‘services’ out of ‘resources’. At runtime, you will be able to generate a WADL which specifies the URIs and supported HTTP methods/verbs (GET, PUT, POST, DELETE) and you can use this to create client-side applications. The JAX-RS specification only provides details for server-side APIs but if you use Jersey then you can take advantage of the classes that it offers to consume REST services.Just like SOAP, the container will take care of mapping your data representation, whether it is in XML or JSON, to your Java POJOs. In addition, JAX-RS takes care of HTTP handshaking and allows you to perform content negotiation at runtime. Also, JAX-RS supports HTTP communication ONLY. There are no other transports supported.
  • Evolution over XML-RPCAllowed you to get around firewalls with HTTPSimply put, a format for sending messages
  • Lets take a look at the arguments that claim REST is better than SOAP.First, RESTful services are lightweight can be consumed by a wide variety of clients – from standalone Java applications to simple browser-based applications using JavascriptREST doesn’t require XML parsing so the CPU requirements are lower than SOAP and REST doesn’t require a SOAP envelope so the messages consume less bandwidthAnother argument is that SOAP is old and all of the ‘new’ or ‘cool’ sites on the internet use REST, and this is very true for many consumer-facing websites and web service providers.In addition, you can learn how to use REST very easily. Its just nouns and verbs – resources and HTTP methods. I don’t have to learn XML and SOAP just to interact with a service producerPlus, REST is safe. I can simply enable passthrough on HTTP GET’s and spend my effort looking at PUTs and DELETEs.
  • Both SOAP and REST have their rightful place within enterprise and consumer applications, and there is no reason they can’t co-exist and support the same enterprise application. REST is ideally suited for exposing data over the internet (or networks in general) and has low bandwidth and CPU requirements. It’s also good for creating mashups of different content from various providers on a web page.However, if you look at the enterprise requirements for messaging, you may find that SOAP is a better fit because it offers enterprise features like High Reliability with WS-RM

Transcript

  • 1.
  • 2. RESTful Services with JAX-RS, JQuery Bonus Content: JSF 2.0
    Jeffrey West
    Application Grid Product Management
  • 3. Questions & Discussion
  • 4. <Insert Picture Here>
    Program Agenda
    JAX-RS / JQuery
    JAX-RS Introduction & Overview
    JAX-RS vs SOAP
    JAX-RS WebLogic Configuration
    JAX-RS Code Review
    JQuery Application Demo
    JQuery Code Review
    JSF 2.0
    JSF 2.0 Application Demo
    JSF 2.0 Code Review
  • 5. 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
  • 6. 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
    • Annotation-driven
    • 7. @Path
    • 8. @Produces/Consumes
    • 9. @HEAD/PathParam/QueryParam
    • 10. @GET/POST/PUT/DELETE
  • WADL - Example
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <application xmlns="http://research.sun.com/wadl/2006/10">
    <doc xmlns:jersey="http://jersey.dev.java.net/"
    jersey:generatedBy="Jersey: 1.1.2-ea-SNAPSHOT 07/28/2009 04:05 PM"/>
    <resources base="http://localhost:7001/HelloRS">
    <resource path="/helloworld">
    <method name="GET" id="getClichedMessage">
    <response>
    <representation mediaType="text/plain"/>
    </response>
    </method>
    </resource>
    </resources>
    </application>
    WADL URL: http://host:port/root_context/application_path/application.wadl
  • 11. Example (Resource class)
    @Path("widgets")@Produces("application/xml, application/json")public class WidgetsResource {@GETpublic WidgetsRepresentationgetWidgetList() { ... }@GET @Path("{id}") public WidgetRespresentationgetWidget(@PathParam("id") String widgetId) { ... }}
  • 12. REST vs. SOAP
  • 13. 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
  • 14. 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
  • 15. REST is better than SOAP!
    REST can be consumed by any client, even a web browser with Ajax and Javascript
    REST is lightweight
    REST doesn’t require XML parsing
    REST consumes less bandwidth – doesn’t require a SOAP header for every message
    SOAP is OLD! All the ‘cool kids’ are using REST!
    Twitter, Google, Flickr
    I can learn to use REST very quickly
    It’s just nouns and verbs, how hard can it be?
    REST is SAFE!
    Aren’t all ‘GET’ operations safe?
  • 16. 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?
  • 17. 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
  • 18. Oracle Parcel Service
  • 19. Oracle Parcel Service
  • 20. JQuery
    Client Side JavaScript designed to simplify JavaScript and create powerful & dynamic websites
    Eases the:
    Navigation of HTML documents
    Queries to select DOM elements
    Creation of Animations
    Handling of Events
    Development of AJAX based applications (which are aligned with consuming RESTful services)
    JQuery is one of the most popular JavaScript libraries uses today: http://trends.builtwith.com/javascript/JQuery
    Free, open-source MIT- and GNU-licensed
  • 21. 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
  • 22. 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