IPT – Intellectual Products & Technologies Trayan Iliev, http://www.iproduct.org/ BGOUG Meeting – Pravets November 14, 2014 Slide 1 Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License Novelties in Java™ EE 7: JAX – RS 2.0 Trayan Iliev IPT – Intellectual Products & Technologies e-mail: [email protected]web: http://www.iproduct.org Oracle®, Java™ and JavaScript™ are trademarks or registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
60
Embed
Novelties in Java EE 7: JAX-RS 2.0 + IPT REST HATEOAS Polling Demo @ BGOUG Conference, Pravets 2014
Presentation shows by example (IPT Polling Demo JAXRS20 HATEOAS, https://github.com/iproduct/IPT-Polling-Demo-JAXRS20-HATEOAS/wiki) the novelties in JAX-RS 2.0 and REST HATEOAS: - Standardized REST Client API; - Client and server-side asynchronous HTTP request processing; - Integration of declarative validation using JSR 349: Bean Validation 1.1; - Improved server-suggested content negotiation; - Aspect-oriented extensibility of request/response processing using Filters and Interceptors; - Dynamic extension registration using DynamicFeature interface; - Hypermedia As The Engine Of Application State (HATEOAS) REST architectural constraint support using state transition links (support for new HTTP Link header as well as JAXB serialization of resource links).
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Oracle®, Java™ and JavaScript™ are trademarks or registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Slide 3Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Agenda II
Improved server-suggested content negotiation in addition to that suggested by clientAspect-oriented extensibility of request/response processing using Filters (non wrapping) and Interceptors (wrapping) client and server extensions
Dynamic extension registration using DynamicFeature interface;
Hypermedia As The Engine Of Application State (HATEOAS) REST architectural constraint support using state transition links (support for new HTTP Link header as well as JAXB serialization of resource links).
Slide 8Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Software Architecture – Definitions [2]
According to Dr. Roy Thomas Fielding [Architectural Styles and the Design of Network-based Software Architectures, 2000]:
A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation,each with its own software architecture.
A software architecture is defined by a configuration of architectural elements - components, connectors, and data - constrained in their relaionships in order to achieve a desired set of architectural properties.
Slide 9Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Software Architecture – Definitions [3]
According to Dr. Roy Thomas Fielding [Architectural Styles and the Design of Network-based Software Architectures, 2000]:
An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
The primary distinction between Network-based architectures and software architectures in general is that communication between components is restricted to message passing, or the equivalent of message passing if a more efficient mechanism can be selected at runtime based on the location of components.
All of them should be present in a desired Web Architecture and REST architectural style tries to preserve them by consistently applying several architectural constraints
Slide 11Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Service Oriented Architecture (SOA) – Definitions
Thomas Erl: SOA represents an open, agile, extensible, federated, composable architecture comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reusable services, implemented as Web services. SOA can establish an abstraction of business logic and technology, resulting in a loose coupling between these domains. SOA is an evolution of past platforms, preserving successful characteristics of traditional architectures, and bringing with it distinct principles that foster service-orientation in support of a service-oriented enterprise. SOA is ideally standardized throughout an enterprise, but achieving this state requires a planned transition and the support of a still evolving technology setReferences: Erl, Thomas. Serviceorientation.org – About the Principles, 2005–06
Slide 15Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Representational State Transfer (REST) [1]
REpresentational State Transfer (REST) is an architecture for accessing distributed hypermedia web-services
The resources are identified by URIs and are accessed and manipulated using an HHTP interface base methods (GET, POST, PUT, DELETE, OPTIONS, HEAD, PATCH)
Information is exchanged using representations of these resources
Lightweight alternative to SOAP+WSDL -> HTTP + Any representation format (e.g. JavaScript™ Object Notation – JSON)
Slide 16Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Representational State Transfer (REST) [2]
Identification of resources – URIs
Representation of resources – e.g. HTML, XML, JSON, etc.
Manipulation of resources through these representations
Self-descriptive messages - Internet media type (MIME type) provides enough information to describe how to process the message. Responses also explicitly indicate their cacheability.
Hypermedia as the engine of application state (aka HATEOAS)
Application contracts are expressed as media types and [semantic] link realtions (rel attribute - RFC5988, "Web Linking")
Slide 17Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Advantages of REST
Scalability of component interactions – through layering the client server-communication and enabling load-balancing, shared caching, security policy enforcement;
Generality of interfaces – allowing simplicity, reliability, security and improved visibility by intermediaries, easy configuration, robustness, and greater efficiency by fully utilizing the capabilities of HTTP protocol;
Independent development and evolution of components, dynamic evolvability of services, without breaking existing clients.
Slide 21Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Web Application Description Language (WADL)
XML-based file format providing machine-readable description of HTTP-based web application resources – typically RESTful web services
WADL is a W3C Member SubmissionMultiple resourcesInter-connections between resourcesHTTP methods that can be applied accessing each resource Expected inputs, outputs and their data-type formatsXML Schema data-type formats for representing the RESTful resources
But WADL resource description is static ... let's make it dynamic!
Източник: http://en.wikipedia.org/wiki/File:Webservices.png, автор: H. VoormannЛиценз: Creative Commons Attribution 3.0 Unported
Slide 22Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
The New Kids on the Block: JSON, JSON Schema & Hyper Schema, Microformats
There are good use cases for WADL (REST resource metadata descriptions): automatic generation of client code & functional REST service tests, client data validation, building of generic REST clients.
WADL is XML (and relies on XML Schema Definitions) – this is a limitation for JavaScript Clients
Welcome JSON Schema & JSON Hyper-Schema !
But there are also Microformats (XHTML Meta Data Profiles –XMDP): e.g. hCard, hReview, hProduct, hCalendar ...
Talking about meta-data: W3C Resource Description Framework (RDF) and Web Ontology Language (OWL)
Slide 23Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Metadata-Representations Proposal (& Questions)
Meta-data can be very useful for generic REST clients and agents crawling the Web!
Meta-data should be dynamically generated
... but can be more stable than the data it describes
Separation of data and meta-data representations (different life-cycles – allows optional retrieval, caching)
Meta-data should be dynamically discoverable using hyper links in resource representations (rel= type/ describedby/ lrdd?)
Separation of Command and Query representations -> optimal representations for each task (possibly with separate MIME types – application/vnd.*+json/xml?)
Slide 24Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Java API for RESTful Web Service (JAX-RS 2.0)
Allows modelling (and more importantly decoupling) of RESTful resource controllers, models and representations – enables HATEOAS: Level 3 in Richardson WebApp Maturity ModelResource Controllers are modelled as Plain Old Java Objects (POJO) + declarative annotations mapping HTTP request & response URIs / Headers / Body / Parameters / Cookies/ to Java Classes / Methods / Method Arguments / Sub-resourcesModels are again POJO + (eventually) some XML / JSON mapping annotations – e.g. JAX-B / Jackson / Jettison / MOXyRepresentations – custom HATEOAS resource representations can be easily build using provided Link class and @XmlJavaTypeAdapter(JaxbAdapter.class) annotation
Източник: http://en.wikipedia.org/wiki/File:Webservices.png, автор: H. VoormannЛиценз: Creative Commons Attribution 3.0 Unported
Slide 29Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Novelties in JAX-RS 2.0 by Example:IPT Polling Demo
You can clone (or download) IPT RESTful Polling Demo at GitHub: https://github.com/iproduct/IPT-Polling-Demo-JAXRS20-HATEOAS
The demo shows how to integrate multiple Java EE 7 technologies: EJB 3.1, CDI 1.1, JPA 2 + EclipseLink, JTA, Bean Validation.
It is a Maven project and can be deployed as Web application (.WAR) or started from command line, as simple as:
mvn embedded-glassfish:run (in project's root folder)
I demonstrates also how to develelop functional/integration tests using embedded GlassFish 4 and maven-surefire / maven-failsafe plugins; to start the integration tests from command line: mvn verify
There is also a project Wiki page discussing the details of the demo:https://github.com/iproduct/IPT-Polling-Demo-JAXRS20-HATEOAS/wiki
Slide 35Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
JAX-RS 2.0: Standardized REST Client API
Java Client API is important for:
RESTful services integration – building composite RESTful services and server-side mashupsFunctional & integration testing of web applications – using JUnit/ TestNG for testing integration scenariosLoad / Perfomance / Stress testing of REST servicesBuilding GUI clients – could utilize rich interface capabilities of Swing & Java FX
Before Java EE 7 each of JAX-RS implementations had its own client API
Now the client code can be standardized and portable between implementations
Slide 36Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Standardized REST Client API Example (1)
public class PollsResourceTest { public static final String BASE_URI = "http://localhost:8080/polling/resources/polls"; private static WebTarget target; ... @BeforeClass public static void setUpClass() { // Initialize base REST client and target URI uri = UriBuilder.fromUri(BASE_URI).build(); ClientConfig config = new ClientConfig(); Client client = ClientBuilder.newClient(config); target = client.target(uri); setupResources(); }
Resource Filters – very similar to “classical” HttpServlet filters, non wrapping, do not invoke next processors in the chain directly, can filter HttpRequest (ContainerRequestFilter, ClientRequestFilter) or HttpResponse (ContainerResponseFilter, ClientResponseFilter). can bypass the next filters and resources by calling: ContainerRequestContext.abortWith(javax.ws.rs.core.Response)
Resource Interceptors – they “wrap” the call to the entity readers/writers by explicitly calling [Reader/Writer]InterceptorContext.proceed() to pass the input stream or entity body read / written by next interceptor / resource/ sub-resource method in the chain.
Filters & interceptors can manipulate headers and entity body. The main difference is that filters can change the requested resource URI (if @PreMatching), while interceptors can not (they are executed after resource processing method has been matched).
Slide 54Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Dynamic extension registration using DynamicFeature interface
Allows dynamic programmatic registration of post-matching providers during JAX-RS setup at deployment time
public void configure(ResourceInfo resourceInfo, FeatureContext context) method called for each resource allows to dynamically decide during application configuration phase which ContainerRequestFilter, ContainerResponseFilter, ReaderInterceptor, WriterInterceptor, and Feature classes to register for that resource / subresource class / method (based on annotations provided for the method for example)
May be annotated with @Provider annotation to be dynamically discovered
Slide 58Licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License
Want to Learn More?
Welcome to IPT Java™ trainings [http://iproduct.org/]:Programming in Java Language - 3 modules
Web Programming with Java Technology: Servlet 3.1, JSP, JSTL, EL, JSF 2.2, Facelets & Templating, AJAX, JSON, WebSocket, SSE, WebRTC
Java Enterprise Technologies (Java EE 7) – EJB 3.2, JSF 2.2, JAX-RS 2.0, Web Services, WebSocket, JMS, CDI, Bean Validation, JPA, JTA, Batch and Concurrency
Service Oriented Architecture (SOA) & Contemporary Standards for Business Process Modeling (BPM) – Apache AXIS 2 & CXF, Glassfish Metro & Jersey, JBoss RESTEasy, SoapUI & Service Testing, SOAP, WSDL 2.0, WS-*, SOA, SCA, SDO, BPMN, WS-BPEL
Java™ Portlet Development with JSR 286: Portlet 2.0 API, Liferay® 6 & GateIn 3 – JSP™, JSF 2.2, Spring & AJAX Portlets
Oracle®, Java™ and JavaScript™ are trademarks or registered trademarks of Oracle and/or its affiliates. Liferay® is a registered trademark of Liferay, Inc. Other names may be trademarks of their respective owners.