Http REST

Http REST

One of the primary reason why REST is simple to use is because REST uses HTTP as not just transport layer but as an API.

HTTP as an API

Http Methods

Any REST services can be accessed only by well-known HTTP methods

          GET   -        Retrieve

          POST -        CREATE

          PUT    -        Update

          DELETE -     Delete

You might argue the SOAP allows to have developer defined methods, whereas here it is limited to these methods. DB has only these operations but still able to meet their expectations, REST will so.

Http Errors

REST client knows about the status of their request from the traditional Http status code 

         

          100 - 199  - Information

          200 – 299 - Success

          300 – 399 - Redirection

          400 – 499 - Client Side Error

          500 – 599 - Server Error

Few of the most commonly seen codes:

          200 – OK

          400 – Bad request

          405 – Method not allowed

          500 – Internal Server Error 

A Recap - Http Servlet:

When we speak about Http methods, the first thing comes to our mind is Http Servlet where we override doGet & doPost methods. However we use these methods interchangeably but in REST it is advisable to use the appropriate method. Since Http servlet is built for http methods it is always the easiest choice to implement REST service.

REST – Representation State Transfer

The Heart of REST is “Resource”, which resides in the server whose state is transferred from client to server and vice-versa.

Resource

Each resource is unique in an application

   Can be identified by URI (uniform resource identifier)

   Can be accessed via Http Methods [GET, POST…]

Representation

A temporal state of the Resource at the time of the request, it can be of any format

     XML

     JSON

     HTML
     Or any other thing which comes in future   

           

The page you are viewing now is the current state of the article represented in html format transferred from server [blogger.com] to the client [your browser].

How is web application different from REST service? Any stateless [does not require user session], Independent web page can be said as REST implementation. Here it is represented in text/html format.

Guidelines to implement REST service

     

    1.   Identify Resources

    2.   Decide the Representation [xml, json, etc]

    3.   Define URI for the resources

    4. At last, lets worry about the implementation technology & frameworks  

  

Jersey [JAX-RS] reference implementation

Jersey [a JAX-RS implementation framework] is one of the most commonly used REST framework. 

Jersey Annotations

URI:

@Path –

a.    Declared at the class level to indicate the class [pojo] is a Resource which can identified by this URI

b.    Declared at Method level to indicate the relate path with in the Resource URI

Http Methods:

@GET

@POST

@PUT

@DELETE

URI Variables:

@PathParam

This is used together with @Path & in conjunction with @GET, @POST, @PUT, @DELETE

Variables in the URI can be read as PathParam in to method

Input & Output Formats

@Consumes

Applicable for @POST & @PUT

The input format the methods support i.e, “application/xml” here. The client will be setting the header “Content-Type” as “application/xml”   
   

 

@Produces

This works with @GET, @POST & @PUT

The client sends HTTP Request together with an Accept Http header that map directly to the content-type the method provider.

Form Param

This allows http form to be submitted to service

Exercise – Built a simple REST service & client using jersey 2

Resource:     Book

Representation: JASON

URI: /book/{bookName}

Fwk: Jersey 2

Rest Service

     1.   Built a simple webapp maven project

     

    2.   Import the  maven project into your workspace

    3. Add Jersey dependencies in project pom.xml

    

   4.  Create a simple Book Resource

      

            Here the java-jason conversion is handled by Jackson framework.

    5.   Configure rest servlet container in web.xml

    6.   Deploy the app to any j2ee container

You can choose your choice of app server.Jetty is a light weight server which I have used for testing this rest service.

Version: jetty-distribution-8.1.0.RC5

Copy the project war to jetty webapp and start the server

java –jar start.jar

   

     7.   Test the service using chrome advance rest client app

           

            URL: http://localhost:8080/LibraryRestService/mylib/book/samplebook

   Method : GET

Upon submitting the request, you should get the below Jason response

 {"name":"sampleBook","author":"xyz","publisher":"abc"}

Rest java Client

    1.   Built a simple java maven project

    

    

   2. Import the  maven project into your workspace

   3. Add Jersey client dependencies 

 

  

  4. Create client

  Here the JacksonFeature will transform the jason to java bean. 

However I had few version issues which I couldn’t resolve, hence I had to use Jackson ObjectMapper to convert Jason to java manually i.e., something similar to below

String content = target.request().get(String.class);

ObjectMapper mapper = new ObjectMapper();

Book response = mapper.readValue(content, Book.class);

  

I hope you would have got some good understanding on REST & JAX-RS/Jackson framework.  

Thank you. Hopefully I'll meet you again in my next article :)

Focus SOAP

SOAP, Payload, RPC, WS, JAXB, SOAP 11, 12, what are all these? How are these used in webservice?  Do you have these question in your mind as well?

I recently read a wonderful book titled "Java Webservices Up & Running" by "Martin Kalin" which explains the internal working of SOAP in detail. I thought of sharing my learning in my own words.

What is SOAP?

SOAP - A XML

In any client/server architecture data needs to be passed in some form. Here it is an xml which is nothing about SOAP.

                                           Components of SOAP Message 

SOAP - An Infrastructure [Transport Neutral]

SOAP can be transported through SMTP, MQ, etc. However HTTP remains most popular SOAP transport protocol.

SOAP - A Contract [WSDL]

SOAP provides a contract/agreement in the form of WSDL [webservice description language], where the service, operations, transport, location, etc are described.

In order to implement a working SOAP model you might be assuming that we have to be well versed with Networking, XML [Service call, XML construction/Parsing, etc]  but that is not the case as there are utilities [available in almost all languages] which makes things simpler. 

Java Support for Webservice - [JaxWS]:

Starting Java 1.5 comes bundled with JAX-WS, which provides utility to generate stub, request, response & dependent class from the wsdl, service.  First version of JAX-WS was called JAX-RPC, whose support is limited to RPC style.

Two styles of SOAP Web services:

RPC [Remote Procedure call] - It supports only simple types like String, Integer, etc.

Document - Can support Complex types. The WSDL type section defines the schema of complex types. By default the style is Document.

RPC Style

Server Side Implementation:

1. Service 

Note: The style is explicitly declared as RPC

2. Publish the Service

In general the service are deployed to J2EE server like tomcat, but to keep things simple the above service will be published in a standalone mode [using Endpoint]

3. WSDL

Up on execution java EndpointPublisher, the service starts and the WSDL can be viewed upon hitting the url http://localhost:9090/calc?wsdl

Takeaway sections from WSDL

types          Defines all complex types involved in the service.
                    Here it will be empty, as RPC is meant for simple types

portType    Defines the service signature, equivalent to java interface
                    i.e., method [operation] name, arguments [input] & return [output]

binding      Can be considered as implementation of above interface [portType]. 
                    This also declares transport,  soap style.  Here the transport – http, & style is RPC

service       Holds the URL where service is available

Client side Implementation:

1. Generate client classes from WSDL

WS import utility will generate required client classes from WSDL. Earlier this utility was called as WSDL-to-Java, now it is renamed to wsimport.

    wsimport -p rpcclient -keep http://localhost:9090/calc?wsdl

where:

p    -     package [files will be generated under this package]
keep -  Retain the Source code of client class

This generates the required stub under rpcclient folder 

2. Client

Where CalcServiceService & CalcService are the wsimport generated classes. The service.getCalcServicePort() returns port [ie.,interface] from which we can make the necessary operation

Upon executing the client, Java CalcClient

Result:                                    output 75.0

Here we deal only with Java objects, however behind the screen it’s all SOAP xml. Jax-Ws takes care of binding java & xml using JAXB [Java API for XML Binding].

Below is the SOAP Request/Response of the above service/client captured using tcpmon. The soap webservice can be invoked directly with soap request with any soap supported tool like soap ui, etc.

Document Style

Server Side Implementation:

1. Service - Remove Style from Service [By default the style is document] 

2. Wsgen utility generates the java types required by publisher to generate WSDL [can be ignored in ede's like eclipse]

       wsgen -cp . learning.websrvc.soap.service.doc.calc.CalcService

3. Publish the DOC service [same like RPC]

4. WSDL View 

Up on execution java EndpointPublisher, the service starts and the WSDL can be viewed upon hitting the url http://localhost:9090/calc?wsdl

One of the key difference between RPC & DOC wsdl is the type section

Here it defines all complex types involved. The complex types can be directly embedded in wsdl or the schema can be imported in to the type section.  

Client Side Implementation: [The same as RPC]

1. Generate client classes from wsdl 

        wsimport -p docclient -keep http://localhost:9090/calc?wsdl

2. Client

Document style is not limited to simple types, this can support complex types as well. WSDL type section holds all complex types involved in service. 

Here Document client looks similar to RPC style i.e., parameterized invocation. This type of client is called Wrapped Client - where the req/response is wrapped to look like parameterized call. There is another type called UnWrapped/BARE client – where the request/response are exposed as it is as single object. These two types differs only on the client side, the soap req/resp does not have any change nor the server side. Wrapped is by default and is commonly used.

UnWrapped/Bare Client

1. Explicitly declare the Wrapper False, in a file name "custombinding.xml", and pass this to wsimport

    wsimport -p rpcclient -keep http://localhost:9090/calc?wsdl –b custombinding.xml

2. Client

Here you can see, the request & response is exposed as it is in SOAP in to a single object Add & AddResponse respectively.

Handlers:

Just like filters in servlet we have handlers in SOAP, which can intercept request, response at both client & service side. Handlers are classified into two types 

1. SOAP Hander -     Has access to SOAP Envelope [Header + Body]

2. Logical Handler - Has access only to the payload [Body]

Handler chain can be configured in the order it needs to get invoked on every in/out. I have seen usecase where the authentication, logging are done at the handlers level. Incase of any failure the handlers can throw Exception [An exception class with getFaultMessage() ]

There are more to it. But I will wrap up here. I believe this will be useful piece of info for you as well. Please don’t forget to leave your feedback, suggestion, improvement comments. 

Thank you!

Memory Management

Lets start from where we left on the earlier post: JVMView

We know each JVM instance is born with a Method Area and a Heap Memory



Heap Memory:

The place where object resides, the Default maximum heap size is 64 Mb, this may be configured with the following VM options as well:

·         -Xmx<size> - to set the maximum Java heap size

·         -Xms<size> - to set the initial Java heap size

Method Area or Non-Heap Area:

This is place where binary code, runtime constant pool, static fields/classes resides. GC will not visit this memory. By default the maximum size of this area is 64 Mb, this may be configured as:

          -XX:MaxPermSize = to set max non heap size

Memory Management:

This is process of managing memory by allocating portion of memory during object creation and reclaiming memory when object is not reachable/referred.

In some programming, reclaiming memory is programmer's responsibility, which is quite complex; developer could spent most of time in debugging. In Java these overhead is taken care automatically by automatic memory management [Garbage Collector]

Garbage Collection Algorithm:

Garbage collection was invented by John McCarthy

Garbage Detection:

As a first step, GC has to detect/identify garbage [objects which are not referred directly/indirectly], for that GC first defines set of roots, from which it will try to reach out to other objects, objects which are not reachable are considered as garbage, because they are no longer required for program execution.

Tracing Approach [All modern JVM prefer this approach]:

Tracing start from root objects and traverse through the whole graph to find out live objects. Objects that are traversed during the trace are marked. After the trace is complete, unmarked objects are known to be unreachable and can be garbage collected. This basic tracing algorithm is called "mark and sweep." 

Yellow are the objects, which are visited by GC during tracing and rest of the objects [dark blue] are considered as non-referred objects and can be garbage collected

So algorithm is quite simple right? Wait!

We all know a real time application is going to have more no. of objects. Expecting GC to traverse through each and every object is going to be time consuming and could degrade the system. Assume a application has some cache objects - which means they are going to be live for long time [if not till the end of the program, at least for some long time] – so GC performance can be improved if it can avoid visiting these kind of long lived objects regularly.

The two important observations about objects:

1. Most objects have very short lives [ex: local objects].
2. Some objects have long lifetimes [ex: Cache objects], and it could refer to any short-lived object as well.

Having these two points as base assumption, GC group’s objects by age, and GC collects younger [short lived] object more often than older [long lived] ones.

Generational Collectors:

In this approach, the heap is divided into two sub-heaps; each serves one generation of objects and garbage will be collected from each heaps separately. 

When an object is created it allocates memory in the younger generation, if the object survives few younger generation garbage collections then the object will get promoted to old generation.

The younger generation is typically small and collected frequently. As most objects are short-lived, only a small percentage of young objects are likely to get promoted to older generation. On the other hand the older generation is typically larger and collected less frequently as it is expected to have long lived objects. 

In order for an object to be retained in younger generation for few cycles, the younger generation is further split in to three areas. 

The Eden: The place where most new objects are allocated, this place is empty after a garbage collection cycle

Two-survivor space: These hold objects, which has survived one garbage collection and have been given another chance to become unreachable before they promoted to old generation. Like shown in the above figure only one survivor space will have object while the other is most of the time empty.

Demonstration of a Minor [Young generation] GC cycle:

• In general all objects will be initially created in Younger generation [Eden space]
• When GC runs in young generation heap[both in eden and from], the object found for garbage are marked as X.  
• Live objects found in the Eden are copied to unused survivor space.
• Live objects in the survivor space [From], which needs to be given another chance, are copied to unused survivor space
• Live objects in the survivor space[From], which are old enough, are promoted to old generation

• Towards the end of the minor GC, the two survivor space swaps space [From <--> To]
• Eden will be empty, one survivor space[From] will have objects and other [To] will be empty

The cycle keeps continuing... At the time of next run: the Eden will be filled by new objects, From will have objects which has survived previous run, and To will be empty as usual. The GC cycle repeats and non-referenced  objects are cleaned up.

With this I assume we have some good understanding how GC deals with short-lived objects.

  

Below are the commonly known garbage collectors:

1. The Serial GC:

For young generation, this GC work in the same way mentioned above

For old generation, it mange by “sliding compacting mark-sweep”

Sliding Compacting Mark-Sweep

After identifying the objects, which are going to live in old generation, it slides them towards the beginning of the heap so that free space will be available as contiguous chunk towards the end. Hence memory allocation for any new object will be easier.

Both Minor and Full GC take place in sequence in a Stop the World fashion; the application will be stopped when GC is in progress.

2. The Parallel GC:

This operates similar to Serial GC [Stop the World Fashion], however both the minor and full garbage collections take place in parallel.

3. The Mostly Concurrent GC:

Also known as Concurrent Mark-Sweep [CMS], manages the young generation in the same way [stop the world fashion], where as the old generation [large part of the heap] is managed concurrently. Unlike other two GC, this does not do the fragmentation, free space are not contiguous as a result allocation into old generation is expensive.

Application, which requires huge heap, tends to opt to this GC. Since Heap is huge the GC is going to take more time, and this does not stop the application while GC is in progress

4. The Garbage-First GC:

This is parallel, concurrent, and compacting low-pause GC.

This does not have physically separate spaces for young and old generation but it is a set of regions which allows this to resize young generation in a flexible way

Detailed description of these GC is beyond the scope of this article.

Notes:

Out Of Memory:When a request is made to create new object, and if heap does not have sufficient space after GC cycle then application crashes with OOM error.

The first thing comes to our mind is to increase the heap size, but before doing that we need to check whether the app really requires huge heap? As the problem might be because of Memory leak, if that is the case then the increased heap might not be sufficient after some period of time. Using Eclipse Memory Analyzer Tool [MAT] we can identify memory leak, there are many such tools available in market. 

Even if you decide to increase heap size, keep in the mind that the huge the heap the more the workload on GC as it has to traverse through the entire heap 

Avoid Object Pooling: Pooled objects are long-lived objects and it will get into Old generation

Sloppy sizing of Array: If Array list is initially sized too small, then its backing array might subsequently needs to be resized several times causing unnecessary allocation

Command Line Tools: -XX:+PrintGCDetails  is command line argument to print the GC information during runtime. This will print Heap [Eden, From, To], Non-Heap memory usage.

References:

http://docs.oracle.com/javase/specs/jvms/se7/html/index.html

http://www.artima.com/insidejvm/ed2/gcP.html

Java Performance by Charlie Hunt & Binu John

http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)

http://www.yourkit.com/docs/kb/sizes.jsp