T6

1. Compare and contrast Message oriented communication with resource oriented communication 

Advantages

Asynchronous Messaging
Message-oriented middleware comprises a category of inter-application communication software that usually relies on asynchronous message-passing, as opposed to a request-response architecture. In case of asynchronous systems, message queues provide temporary storage when the destination program is busy or unable to get connected. Apart from this, most asynchronous MOM systems provide persistent storage to back up the message queue which means sender and receiver does not necessarily connect to the network at the same time (asynchronous delivery), and problems with irregular connectivity are also solved. If the receiver application fails for any reason, the senders can continue uninterrupted, as messages which are sent will automatically accumulate in the message queue for processing when the receiver restarts.

Routing
Many message-oriented middleware implementations depend on a message queue system. Most implementations have routing logic provided by the messaging layer itself, while very few depend on client applications to provide routing information or allow both paradigms. Some implementations make use of broadcast or multicast distribution paradigms.

Transformation
In a message-based middleware system, the message received at the destination need not be identical to the message originally sent. A MOM system with built-in intelligence can transform messages en route to match the requirements of the sender or of the recipient. In conjunction with the routing and broadcast/multicast facilities, one application can send a message in its own native format, and two or more other applications may each receive a copy of the message in their own native format. Many modern MOM systems provide sophisticated message transformation (or mapping) tools which allow programmers to specify transformation rules applicable to a simple GUI drag-and-drop operation.

Disadvantages
The primary disadvantage of many message-oriented middleware systems is that they require an extra component in the architecture, the message transfer agent (message broker). As with any system, adding another component can lead to reductions in performance and make the system as a whole more difficult and expensive to maintain.  When introduced due to lack of standards governing the use of message-oriented middleware has caused problems. Most of the major vendors have their own implementations, each with its own application programming interface (API) and management tools.

MOM - Implementation
The message queue is a fundamental concept within MOM. Queues provide the ability to store messages on a MOM platform. MOM clients are able to send and receive messages to and from a queue. Queues are central to the implementation of the asynchronous interaction model within MOM. Usually the messages contained within a Queue is sorted in a particular order. The standard queue found in a messaging system is the First-In First-Out (FIFO) queue; as the name suggests, the first message sent to the queue is the first message to be retrieved from the queue. Many attributes of a queue can be configured. These include the queue’s name, queue’s size, the save threshold of the queue, message-sorting algorithm etc. Typically each application may have its own queue, or applications may share a queue, there is no restriction on the set-up. MOM platforms support multiple queue types for different purposes.

MOM - Messaging Models
A solid understanding of the available messaging models within MOM is key to appreciate the unique capabilities it provides. Two main message models that are commonly available, the point-to-point and publish/subscribe models. Both of these models are based on the exchange of messages through a channel (queue). A typical system will utilize a mix of these models to achieve different messaging objectives.

Point-to-Point Model
The point-to-point messaging model provides a straightforward asynchronous exchange of messages between software entities. In this model, messages from producing clients are routed to consuming clients via a queue. As discussed earlier, the most common queue used is a FIFO queue, in which messages are sorted in the order. While there is no restriction on the number of clients who can publish to a queue, there is usually only a single consuming client, although this is not a strict requirement. The model allows multiple receivers to connect to the queue, but only one of the receivers will consume the message. The techniques of using multiple consuming clients to read from a queue can be used to easily introduce smooth, efficient load balancing into a system. In the point-to-point model, messages are always delivered and will be stored in the queue until a consumer is ready to retrieve them.

Publish/Subscribe Model
The publish/subscribe messaging model, is a mechanism used to disseminate information between anonymous message consumers and producers. These one-to-many and many-to-many distribution mechanisms allow a single producer to send a message to one user or potentially hundreds of thousands of consumers. In the publish/subscribe (pub/sub) model, the sending and receiving application is free from the need to understand anything about the target application. It only needs to send the information to a destination within the publish/subscribe engine. The engine will then send it to the consumer. Clients producing messages “publish” to a specific topic or channel, these channels are then “subscribed” to by clients wishing to consume messages. The service routes the messages to consumers on the basis of the topics to which they have subscribed as being interested in. Within the publish/subscribe model, there is no restriction on the role of a client; a client may be both a producer and consumer of a topic/channel.

2. Discuss the resource based nature of the REST style 

•Things vs Actions 
•Nouns vs Verbs 
•Identified by URIs
•Multiple URIs may refers to same resource
•Separate from their representations 

3. Explain the meaning of “representations” in REST style

It means REST architecture could have multi level cache at client and server ends. ... Resource — There must be resources with their unique resource identifier i.e. unique url in REST APIs. Representations — Representation is the value/response of the Resource at a point in time based on the media-type.

•Typically JSON or XML
      •Or even can be a web page, file, image, etc…

•E.g. The state of a student (as per the database) can be represented by a resource of webpage, XML dataset, etc…

 4. Discuss the constraints of REST, indicating their use in the domain of web

Constraint #1: Client-Server Architecture
The first constraint proposed by REST is the separation of the server from its client. You should encourage separation of concerns between your server and clients wherever possible. Your goal should be to maximize the division of labor — and minimize overlap — between the two.
The server, or back end, is typically responsible for storing your application’s persistent data, along with all the business logic required to interact with it. This could include user authentication, authorization, data validation, and so on.

Constraint #2: Statelessness
The next important constraint proposed by REST is that of statelessness.
Broadly speaking, the main goal of a stateless service is to make incoming requests self-sufficient, and execute them in complete isolation.
Each request must have all the information that the server might need to properly process it and respond. In other words, the server does not need to use information from previous requests. The responsibility of maintaining the application state of a client is thus handed off to the client itself.

Constraint#3: Cache
The third constraint is that of explicit cacheability. The idea is to mark messages returned by a service as explicitly cacheable or non-cacheable. If they’re cacheable, the server should figure out the duration for which the response is valid.
If the client has access to a valid cached response for a given request, it avoids repeating the same request. Instead, it uses its cached copy. This helps alleviate some of the server’s work, and thus contributes to scalability and performance.
This is a form of optimistic replication — also known as lazy replication — where the service does not try to guarantee 100% consistency between itself and its clients unless absolutely critical. Instead, it makes this sacrifice in exchange for a gain in perceived performance.

5. Identify contemporary examples of different types of implementations for the elements of REST style
As stated earlier in the previous article of REST , the REST style is an abstraction of the architectural elements within a distributed hypermedia system. REST distinguishes three classes of architectural elements, they are:


          1. Components
          2. Connector
          3. Data
       
Components

In REST, the various software that interacts with one another are called components. They are categorized by roles summarized in the table below:

Component Role	Description	Example
Origin Server	Uses a server connector to receive the request, and is the definitive source for representations of its resources. Each server provides a generic interface to its services as a resource hierarchy.	Apache httpd, Microsoft IIS
User Agent	Uses a client connector to initiate a request and becomes the ultimate recipient of the response.	Browser like Netscape Navigator etc
Gateway	Act as both, client and server in order to forward - with possible translation - requests and responses.	Squid, CGI, Reverse Proxy
Proxy		CERN Proxy, Netscape Proxy, Gauntlet

Connector

Connectors represent the activities involved in accessing resources and transferring representations. Roles provide an interface for components to implement. REST encapsulates different activities of accessing and transferring representations into different connector types. The table below summarizes the connector types:

Connector Type	Description	Example
Client	Sending requests, receiving responses.	HTTP library
Server	Listening for requests, sending responses.	Web Server API
Cache	Can be located at the client or server connector to save cacheable responses, can also be shared between several clients	Browser cache
Resolver	Transforms resource identifiers into network addresses.	bind (DNS lookup library)
Tunnel	Relays requests, any component can switch from active behavior to a tunnel behavior.	SOCKS, SSL after HTTP CONNECT

Data

The key aspect of REST is the state of the data elements, its components communicate by transferring representations of the current or desired state of data elements. REST identifies six data elements: a resource, resource identifier, resource metadata, representation, representation metadata, and control data, shown in the table below:

Data Element	Description	Example
Resource	Any information that can be named is a resource. A resource is a conceptual mapping to a set of entities not the entity itself. Such a mapping can change over time. In general, a RESTful resource is anything that is addressable over the Web.	Title of a movie from IMDb, A Flash movie from YouTube, Images from Flickr etc
Resource Identifier	Every resource must have a name that uniquely identifies it. Under HTTP these are called URIs. Uniform Resource Identifier (URI) in a RESTful system is a hyperlink to a resource. It is the only means for clients and servers to exchange representations of resources.The relationship between URIs and resources is many to one. A resource can have multiple URIs which provide different information about the location of a resource.	Standardized format of URI:scheme://host:port/path?queryString#fragmente.g:http://some.domain.com/orderinfo?id=123
Resource metadata	This describes the resource. A metadata provides additional information such as location information, alternate resource identifiers for different formats or entity tag information about the resource itself.	Source link, vary
Representation	It is something that is sent back and forth between clients and servers. So, we never send or receive resources, only their representations. A representation captures the current or intended state of a resource. A particular resource may have multiple representations	Sequence of bytes, HTML document, archive document, image document
Representation metadata	This describes the representation.	Headers (media-type)
Control data	This defines the purpose of a message between components, such as the action being requested.	If-Modified-Since, If-Match

 6. Explain how to define the API of RESTful web services using RESTful URLs 
Building RESTful web services, like other programming skills is part art, part science. As the Internet industry progresses, creating a REST API becomes more concrete with emerging best practices. As RESTful web services don't follow a prescribed standard except for HTTP, it's important to build your RESTful API in accordance with industry best practices to ease development and increase client adoption.

Presently, there aren't a lot of REST API guides to help the lonely developer. RestApiTutorial.com is dedicated to tracking REST API best practices and making resources available to enable quick reference and self education for the development crafts-person. We'll discuss both the art and science of creating REST Web services

7. Discuss the pros and cons of using MVC for RESTful web service development, indicating the application of MVC in RESTful web service design 
Difference between MVC and Web API

There are many differences between MVC and Web API, including:

We can use the MVC for developing  the Web application that replies as both data and views but the Web API is used for generating the HTTP services that replies only as data.
In the Web API the request performs tracing with the actions depending on the HTTP services but the MVC request performs tracing with the action name.
The Web API returns the data in various formats, such as JSON, XML and other format based on the accept header of the request. But the MVC returns the data in the JSON format by using JSONResult.
The Web API supports content negotiation, self hosting. All these are not supported by the MVC.
The Web API includes the various features of the MVC, such as routing, model binding but these features are different and are defined in the "System.Web.Http" assembly. And the MVC features are defined in the " System.Web.Mvc" assembly.
The Web API helps the creation of RESTful services over the .Net Framework but the MVC does not support.

8.Discuss the JAX-RS API and its implementations 

JAX-RS: Java API for RESTful Web Services (JAX-RS) is a Java programming language API spec that provides support in creating web services according to the Representational State Transfer (REST) architectural pattern. JAX-RS uses annotations, introduced in Java SE 5, to simplify the development and deployment of web service clients and endpoints.



difference between Jersey and JAX RS
JAX-RS is an specification (just a definition) and Jersey is a JAX-RS implementation. Jersey framework is more than the JAX-RS Reference Implementation. Jersey provides its own API that extend the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development 

9. Identify the annotations in JAX-RS, explaining their use 
Annotations in the JAX-RS API are used to provide meta-data around the web resource. A typical example is to use the @GET annotation with the @Path annotation to identify the method that should handle a GET request to the specified URI in the @Path annotation.

The @Path Annotation

Next, comes the URI path to the resource. In a bookshop application, this might be /books/.

@Path("/books")

public class BookResource {}

The @GET HTTP Method Annotation

Methods annotation with the @GET annotation respond to HTTP get requests.

@GET

@Produces(MediaType.APPLICATION_JSON)

public Response getAllBooks() {

    List<Book> books = BookRepository.getAllBooks(); // queries database for all books

    GenericEntity<List<Book>> list = new GenericEntity<List<Book>>(books) {};

    return Response.ok(list).build();

}

The @PUT HTTP Method Annotation

The @PUT annotation is used for updating a record and method annotated this way respond to an HTTP PUT request.

@PUT

@Consumes(MediaType.APPLICATION_JSON)

@Produces(MediaType.APPLICATION_JSON)

public Response updateBook(Book book) {

    book = bookRepository.updateBook(book);

    return Response.ok(book).build();

}

The @DELETE HTTP Method Annotation

Methods annotated @DELETE are expected to delete a resource.

@DELETE

@Path("{isbn}")

@Produces(MediaType.APPLICATION_JSON)

public Response deleteBook(@PathParam("isbn") String isbn) {

    Book book = bookRepository.deleteBookByIsbn(isbn);

    return Response.ok(book).build();

}

Usually, the resource or its id is passed to the resource method parameter from the URI variable as you can see in this example.

10. Explain the use and importance of “media type” in JAX-RS 

@Consumes and @Produces

All resource methods can consume and produce content of almost any type. If you make a POST request to a URI, such as api/books, the REST API expects the HTTP body to contain a payload that represents the resource it should create.

This resource can be represented using any media type. Although typically, it will be represented in either, JSON or XML, but it could be plain text, binary or a custom format. It doesn’t matter, as long as there is a method in the resource class that can consume that media type.