JavaOne 2013 – Part III

Developing Modern HTML5 Applications with Eclipse Tools

My first session of the day was in another full room. The argument was made by Cameron Bateman that even with all the new browser-based IDEs coming down the line, there will always be a need for local desktop based IDEs like Eclipse. Cameron guided us through creating an application using HTML5, CSS3, JavaScript and REST, showing how to use the Eclipse Web Tools Platform (WTP), he starting by creating a new project, adding some project facets and then writing a very simple demo. The process did look very simple with the help of the plugins mentioned below. I wasn’t previously aware of the Chrome Dev Tools plugin for Eclipse which allows you to use the familiar debugging environment of Eclipse when debugging JavaScript for a webpage in Chrome. You just simply link your project with your JavaScript source code, select the Chrome tab to debug and off you go.

Plugins used included:

  • Oracle Enterprise Pack for Eclipse (OEPE)
  • JPA Tools
  • RunJettyRun

    The sample application can be found on GitHub at https://github.com/CBatemanOracle/javaone2013

    The following snippets of code show just how simple it is to use AJAX and REST to fetch data using jQuery and JAX-RS.

    jQuery:

    function SayHello() {
    	var message = $(“input”).val();
    	$.ajax({
    		url: “/JavaOneRest/rest/hello/” + message,
    		success: function(data) {
    			$(“#message”).text(data);
    		}
    	});
    }
    

    JAX-RS:

    @Path("/hello")
    public class HelloService {
    	@GET
    	@Path("/{param}")
    	public Response printMessage(@PathParam("param") String msg) {
    		String result = msg;
    		return Response.status(200).entity(result).build();
    	}
    }
    

    Beautiful REST + JSON APIs with JAX-RS and Jersey

    Another packed room, I appear to have selected some of the popular sessions today. The talk was given by the CTO of Stormpath, Les Hazlewood, where he gave an overview of best practices he and his team discovered over the last 18 months while building a large product using REST, JSON and JAX-RS. The talk initially focused on REST fundamentals and design principles.

    REST is an architectural style and not a specification and for this reason, there are a lot of different interpretations about how REST should work. So it really is a good idea to be aware of the best practices before you start implementing your own system!

    So why use REST? Dr. Roy Fielding, in his thesis on the topic, listed six reasons: Scalability, Generality, Independence, Latency (Caching), Security, and Encapsulation. Personally I believe it makes for very simple and clean interaction between the client and server, its light weight (for the client anyway), allows for auto discovery and doesn’t force any language, framework or any other jazz on those that wish to consume your services.

    The first design principal mentioned, or as some believe, a restriction on REST was

    HATEOAS – Hypermedia As The Engine Of Application State

    This boils down to meaning: “When a system interacts with another REST based system, it doesn’t need any information beyond the initial request in order to figure out how to continue to interact with that system”

    By using HATEOAS, you make your system auto discoverable by other systems. Les believes this to be one of the cleanest ways to go about implementing REST.

    It’s always preferred to make a good start, and this can be done by selecting good, easy to use endpoints to access your application. Some of the fundamentals highlighted were to use nouns rather than verbs when selecting the endpoint name and be coarse grained.

    Instead of using:

  • /getAccount
  • /getAllAcounts
  • /createAccount
  • /deleteAccount

Keep things simple, and maintainable, by using a coarse grained approach:

  • /accounts/ – (GET)
  • /accounts/a1b2c3 – (GET, PUT, POST, DELETE)

When it comes to behaviour POST, GET, PUT, DELETE is not a one to one mapping against Create, Read, Update and Delete.

Instead:

  • GET = Read
  • HEAD = Header, no body
  • DELETE = Delete
  • PUT, POST = Create and Update
  • GET, HEAD and DELETE are straight forward

GET

GET /accounts/a1b2c3

Response:
200 OK
{
	“href”: “https://api.yourserver.com/accounts/a1b2c3”,
	“name”: “Best App Ever”,
	...
}

DELETE

DELETE / accounts /a1b2c3

Response:
200 OK

HEAD

HEAD /accounts/a1b2c3

Response:
200 OK
{
	“href”: “https://api.yourserver.com/accounts/a1b2c3”,
	“name”: “Best App Ever”,
	...
}

PUT and POST are a little different for the above three. PUT is idempotent and can be used to create a new entity, IF the client knows the value of the identifier of the entity. All data of the entity should be sent in the message as a full replacement and partial updates should not be supported.

PUT – create

PUT /accounts/clientSpecifiedId
{
	“name”: “Best App Ever”
	...
}

Response:
201 Created
Location: https://api.yourserver.com/accounts/a1b2c3

PUT – update (all data must be sent)

PUT /accounts/clientSpecifiedId
{
	“name”: “Best App Ever”
	...
}

Response:
200 OK
Location: https://api.yourserver.com/accounts/a1b2c3

POST however, is not idempotent and can be used to create a new entity where you don’t have an existing identifier or if you are completing a partial update.

POST – create

POST /accounts
{
	“name”: “Best App Ever”
}

Response:
201 Created
Location: https://api.yourserver.com/accounts/a1b2c3

POST – update

POST /accounts
{
	“name”: “Best App Ever”
}

Response:
200 OK
Location: https://api.yourserver.com/accounts/a1b2c3

Other topics covered in the session included:

  • Behaviour – How to interact with your domain resources (GET, DELETE, HEAD, PUT & POST)
  • Media Types – application/json+foo
  • Versioning – Via URL (/v1/rest) or Media Type (Applications/json+foo;application&v=1)
  • Timestamps – Use the existing standard – ISO 8601 and use UTC!
  • HREF – Include in response rather than IDs, ever resource has a unique URL.
  • Response Body – Should you return the same information that was sent to you?

It was a two hour session, with the above really only covering the thirty or so minutes. If you are working with REST, I would highly recommend watching the full session on YouTube at http://www.youtube.com/watch?v=ITmcAGvfcJI

You can try the demo out yourself using:

git clone https://github.com/stormpath/todos-jersey
mvn jetty:run

Spoilt for Choice – Which Integration Framework to choose?

As the title would suggest, the goal of this session was to cover some of the main integration frameworks. We were given a quick overview of Integration Frameworks followed by a comparison of Spring Integration, Mule, Apache Camel and if to use an ESB solution instead. A wish list for integrators was presented as

  • Standardized Modelling
  • Efficient Realization
  • Automatic Testing

The speaker recommended reading Enterprise Integration Patterns if you are working in this area.

Spring Intergration

License: Apache License
Connectivity: lots supported, easy to create your own.
DSL: XML, Groovy (not prod ready), Scala (not prod ready)
Tooling: Eclipse plugins (Graphical designer editor)

Mule (Mule ESB)

License: Common Public Attribution License (CPAL) NB: (more restrictive!)
Connectivity: more than Spring, including B2B connectors (SAP, PayPal, JIRA, SalesForce etc) , easy to create your own.
DSL: XML only
Tooling: Eclipse plugins (Graphical designer with drag and drop). Mule Studio

Apache Camel

License: Apache License
Connectivity: by far the most connectors, easy to create your own.
DSL: XML, Java, Groovy, Scala, Kotlin (not prod ready)
Community: Lots of information and sources, best of the three.
Tooling: Eclipse plugins (fuse) (Graphical designer with drag and drop), FuseIDE / Talend Studio.

Who is the winner? Well all three appear to be very good, but the recommendation from the speaker was to stick with Spring Integration if you are already using Spring in your projects, but otherwise try to use Apache Camel. From the information presents, it would be hard not to choose Apache Camel.

Slides can be reviewed online

Lambdas and retro gaming

While this session intended to create a sprite game with Mary and her ten little lambs (a pun on lambdas) walking across a 10×7 grid, it was really a session about iterating across objects and grid. Each step of the game had two versions, one in Java 7 and a second in Java 8, using lambdas.

Each of the new features of lambdas was used, Colleciton.forEach, lambdas functions, streams and filters. Functional programming and Lambdas is big news and getting bigger all the time, but just looking at some of the code I want to scream and run away. Its a new way of thinking, but at the moment, this new “simpler” code doesn’t look very simple at all.

public static Predicate checkIfLambIs(Integer number) {
	return lamb -> lamb.getNumber() % 4 == number;
}

@Override
public void visit(Shepherd s) {
	s.getAnimals().stream()
		.filter(checkIfLambIs(1)).forEach(a -> a.setColor(null));
	s.getAnimals().stream()
		.filter(checkIfLambIs(2)).forEach(a -> a.setColor(Color.YELLOW));
	s.getAnimals()
		.stream().filter(checkIfLambIs(3)).forEach(a -> a.setColor(Color.CYAN));
	s.getAnimals()
		.stream().filter(checkIfLambIs(0)).forEach(a -> a.setColor(Color.GREEN));
}

static Function<Color, Predicate> checkIfLambColorIs = color -> {
	Predicate checkIfColorIs = lamb -> lamb.getColor() == color; 
	return checkIfColorIs;
};

@Override
public void visit(Shepherd s) {
	mealsServed.set(mealsServed.get() + 
		s.getAnimals()
		.filtered(checkIfLambColorIs.apply(todayEatableColor))
		.size());
	s.getAnimals()
		.removeIf(checkIfLambColorIs.apply(todayEatableColor));
}

Slides can be downloaded here

The Modern Java Web Developer

Matt Raible is well known within the Java web development community and I was really looking forward to attending this session, but unfortunately missed out on due to work commitments. Matt always has his finger on the pulse when it comes to the latest and best Java web technology and its really worth while checking out whatever he mentions. While I was unable to attend this session, Matt’s slides are really well put together and easy to follow for any Java web developer out there. I really like slide eight and think I need may give a hint or two to my boss about it! Check out Matt’s slides here

  1. Leave a comment

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: