martes, julio 08, 2014

RxJava + Java8 + Java EE 7 + Arquillian = Bliss



Microservices are an architectural style where each service is implemented as an independent system. They can use their own persistence system (although it is not mandatory), deployment, language, ...

Because a system is composed by more than one service, each service will communicate with other services, typically using a lightweight protocol like HTTP and following a Restful Web approach. You can read more about microservices here: http://martinfowler.com/articles/microservices.html

Let's see a really simple example. Suppose we have a booking shop where users can navigate through a catalog and when they find a book which they want to see more information, they click on the isbn, and then a new screen is opened with detailed information of the book and comments about it written by readers.

This system may be composed by two services:
  • One service to get book details. They could be retrieved from any legacy system like a RDBMS.
  • One service to get all comments written in a book and in this case that information could be stored in a document base database.
The problem here is that for each request that a user does we need to open two connections, one for each service. Of course we need a way do that jobs in parallel to improve the performance. And here lies one problem, how we can deal with this asynchronous requests? The first idea is to use Future class. For two services may be good but if you require four or five services the code will become more and more complex, or for example you may need to get data from one service and using it in another services or adapt the result of one service to be the input of another one. So there is a cost of management of threads and synchronization.

It will be awesome to have some way to deal with this problem in a clean and easy way. And this is exactly what RxJava does. RxJava is a Java VM implementation of Reactive Extensions: a library for composing asynchronous and event-based programs by using observable sequences.

With RxJava instead of pulling data from an structure, data is pushed to it which reacts with an event that are listened by a subscriber and acts accordantly. You can find more information in https://github.com/Netflix/RxJava.


So in this case what we are going to implement is the example described here using RxJava, Java EE 7, Java 8 and Arquillian for testing.

This post assumes you know how to write Rest services using Java EE specification.

So let's start with two services:




And finally it is time to create a third facade service which receives communication from the client, sends to both services in parallel a request and finally zip both responses. zip is the process of combining sets of items emitted together via a specified function and sent it back to client (not to be confused with compression :)).


Basically we create a new service. In this case URLs of both services we are going to connect are hardcoded. This is done for academic purpose but in production-like code you will inject it from a producer class or from properties file or any system you will use for this purpose. Then we create javax.ws.rs.client.WebTarget for consuming Restful Web Service.

After that we need to implement the bookAndComment method using RxJava API.

The main class used in RxJava is rx.Observable. This class is an observable as his name suggest and it is the responsible of firing events for pushing objects. By default events are synchronous and it is responsible of developer to make them asynchronous.

So we need one asynchronous observable instance for each service:

Basically we create an Observable that will execute the specified function when a Subscriber subscribes to it. The function is created using a lambda expression to avoid creating nested inner classes. In this case we are returning a JsonObject as a result of calling the bookinfo service. The result is passed to onNext method so subscribers can receive the result. Because we want to execute this logic asynchronously, the code is wrapped inside a Runnable block.

Also it is required to call the onCompleted method when all logic is done.

Notice that because we want to make observable asynchronous apart of creating a Runnable, we are using an Executor to run the logic in separate thread. One of the great additions in Java EE 7 is a managed way to create threads inside a container. In this case we are using ManagedExecutorService provided by container to span a task asynchronously in a different thread of the current one.

Similar to previous but instead of getting book info we are getting an array of comments.

Then we need to create an observable in charge of zipping both responses when both of them are available. And this is done by using zip method on Observable class which receives two Observables and applies a function to combine the result of both of them. In this case a lambda expression that creates a new json object appending both responses.

Let's take a look of previous service. We are using one of the new additions in Java EE which is Jax-Rs 2.0 asynchronous REST endpoints by using @Suspended annotation. Basically what we are doing is freeing server resources and generating the response when it is available using the resume method.

And finally a test. We are using Wildfly 8.1 as Java EE 7 server and Arquillian. Because each service may be deployed in different server, we are going to deploy each service in different war but inside same server.

So in this case we are going to deploy three war files which is totally easy to do it in Arquillian.

In this case client will request all information from a book. In server part zip  method will wait until book and comments are retrieved in parallel and then will combine both responses to a single object and sent back to client.

This is a very simple example of RxJava. In fact in this case we have only seen how to use zip method, but there are many more methods provided by RxJava that are so useful as well like take(), map(), merge(), ... (https://github.com/Netflix/RxJava/wiki/Alphabetical-List-of-Observable-Operators)

Moreover in this example we have seen only an example of connecting to two services and retrieving information in parallel, and you may wonder why not to use Future class. It is totally fine to use Future and Callbacks in this example but probably in your real life your logic won't be as easy as zipping two services. Maybe you will have more services, maybe you will need to get information from one service and then for each result open a new connection. As you can see you may start with two Future instances but finishing with a bunch of Future.get() methods, timeouts, ... So it is in these situations where RxJava really simplify the development of the application.

Furthermore we have seen how to use some of the new additions of Java EE 7 like how to develop an asynchronous Restful service with Jax-Rs.

In this post we have learnt how to deal with the interconnection between services andhow to make them scalable and less resource consume. But we have not talked about what's happening when one of these services fails. What's happening with the callers? Do we have a way to manage it? Is there a way to not spent resources when one of the service is not available? We will touch this in next post talking about fault tolerance.

We keep learning,
Alex.
Bon dia, bon dia! Bon dia al dematí! Fem fora la mandra I saltem corrents del llit. (Bon Dia! - Dàmaris Gelabert)
Music: https://www.youtube.com/watch?v=BF7w-xJUlwM

lunes, junio 09, 2014

Injecting properties file values in CDI using DeltaSpike and Apache TomEE


One of the great improvement in Java EE 5 and beyond it is the introduction of CDI (Context and Dependency Injection). CDI is used for injecting dependencies among a lot of other things like events, interceptors, … and can be used in POJOs.

In some cases instead of injecting other objects (as a dependency injection), you want to inject a value from a properties file into a class that needs to be configured externally.

I have written an example in Tomitribe community zone: https://github.com/tomitribe/community/tree/master/injecting-properties 

We keep learning,
Alex.


Sora ni akogarete  sora wo kakete yuku, Ano ko no inochi wa hikoukigumo (The Wind Rises - Joe Hisaishi, Yumi Arai)

lunes, mayo 19, 2014

Java Cookbook Review




This new edition of Java cookbook is an amazing update of the book which covers a lot of the new features implemented in Java 8. 

The author writes in a clear and concise way how to solve some of the most of basic problems you will encounter in your day to day work in Java.

The book shows you from how to concatenate two strings to use functional interfaces.

Definitely if you have already had some experience (1-2 years) in Java and wants to improve your skills inside Java world, this book is for you. 

But it is even more, if you are a Java6 developer and want to update to Java7 or 8 this book is also for you. The author has taken the time to explain not only how to solve a problem using previous concepts of Java but also using the new ones.
In my opinion the book has only one contra, and it is that although new chapters about new Java API like javax.time has been added, the book spends so much pages on explaining some "outdated" technology like Swing or AWT.

Really pleasant book to read, very concise about what is the problem to be resolved, and although you consider yourself as a Java "expert", you will learn something for sure.

Testing Polyglot Persistence Done Right [slides]


This week I was at Krakow in the amazing conference called GeeCon. My talk was "Testing Polyglot Persistence Done Right" and it was cospoken with my friend Bartosz Majsak.

The abstract was:

"Data storage is one of the most crucial parts of any applications, and we use many different tools and tricks to keep it in a good shape. We frequently use both old school relational systems with new approaches commonly known as NoSQL. We write sophisticated queries and use optimization techniques to give our end users the greatest possible experience.
So why is persistence very often skipped in the testing efforts? Is it really that complex and painful to setup? During this talk we will have a closer look at Arquillian Persistence Extension together with NoSQLUnit. These tools remove that burden and boilerplate to make you a happy and productive programmer again! Join this session and see for yourself that writing tests for your data storage logic is as easy as writing normal unit tests!"

And here you can see the slides (http://www.slideshare.net/asotobu/testing-polyglot-persistence-done-right). If you have any question don't hesitate to approach us.



We keep learning,
Alex.
En los mapas me pierdo. Por sus hojas navego. Ahora sopla el viento, cuando el mar quedó lejos hace tiempo. (Pájaros de Barro - Manolo García)

Music: https://www.youtube.com/watch?v=9zdEXRKJSNY


lunes, abril 21, 2014

JPA Tip: Inject EntityManager instead of using PersistenceContext


Almost all projects you develop with Java EE will contain a persistence layer and probably you will use JPA for dealing with SQL systems. One way to get an EntityManager is using @PersistenceContext. In this post we are going to explore the advantages of injecting EntityManager instead of using PersistenceContext annotation.

I have written the example and the explanation on github using Docstract.  You can read on https://github.com/tomitribe/community/tree/master/injecting-entitymanager.

We keep reading,
Alex
Pistol shots ring out in the bar-room night, Enter Patty Valentine from the upper hall, She sees a bartender in a pool of blood, Cries out, "My God, they killed them all" (Hurricane - Bob Dylan)

Music: https://www.youtube.com/watch?v=hr8Wn1Mwwwk

lunes, abril 14, 2014

Docstract-0.2.0 Released.


Docstract is an small java project which reads a java source file, extracts the comments between /** and */ sequentially from all over the file and stores them inside an output AsciiDoc file. The idea is not new in fact it is from https://github.com/javaee-samples/javaee7-samples/ developed by Aslak Knutsen but instead of using Ruby and inside Awestruct, this project is written in java and it is run from CLI.

Let me show you an example to understand what this application does:

This is a class which contains some comments to be processed.

And the output document looks like:

Note that in comments we are also using include macro for inserting files inside. The rules for inclusion are the next ones:

  • if include contains a java file, like first example, the whole class is read and inserted within AsciiDoc source code blocks.
  • if include contains a java file but with # symbol, like second one, the right part of # will be used as method name of given class. So for example Project#setId(String, String) will include a method of Project's class called setId and receiving two string parameters.
  • if include contains an xml file, the file is inserted "as is" within AsciiDoc source code block.
  • if include contains an xml file and between brackets there is an xpath expression, the result of that expression will be inserted.
  • any other include is left "as is", so it will be processed by AsciiDoc(tor) processor.

Also note that the include files will be resolved relative from place where the CLI is being run, typically from the root of the project.

You can use callouts inside java and xml code and the processor will render it in the proper way.

In java you can write a callout as a single line comment with callout number between <, > at start.

In xml you can write callouts between +xml+ comments and the callout number being the first word.

You can grab a runnable jar from https://bintray.com/lordofthejars/generic/Docstract/0.2.0/view/files

To render previous class we can call as:

java -jar docstract-<version>.jar --input=src/test/java/com/lordofthejars/asciidoctorfy/MM.java --output=README.adoc


And an AsciiDoc file will be generated from comments blocks.

There is one optional parameter called --baseDir. This parameter is used to set the baseDir in include macros. So for example if you set baseDir to /home/lotj/project, the include macro will be resolved to include::/home/lotj/project/src/test/java/....


New features will be added when they are required but of course feel free to clone and improve it.


We Keep Learning,
Alex.
Weiß mit dem Locken umzugehn, Und mich auf's Pfeifen zu verstehn. Drum kann ich froh und lustig sein, Denn alle Vögel sind ja mein. (Die Zauberflöte - Wolfgang Amadeus Mozart)
Music: https://www.youtube.com/watch?v=PRtvVQ1fq8s

miércoles, marzo 26, 2014

Apache TomEE + NoSQL (writing your own resources)



@Resource annotation appeared for the first time in Java EE 5 specification.  When you annotate an attribute with @Resource, it will be the container responsible of injecting the requested resource. The typical example is used with DataSource class.

That's great and you can use it with JMS as well, but what's happening to NoSQL databases, would not it be perfect to do something similar for them?

With Apache TomEE you can do it by providing your own @Resource provider class. In this post we are going to see how you write your own provider for MongoDB so you can use @Resource for MongoDB too.

The first thing to do is create the provider class, which is a simple POJO:

It is a simple POJO with a method which returns a MongoClient class (the base class for Java MongoDB driver), and setters with required parameters.

Next step is creating a file called resources.xml in WEB-INF directory. In this file we configure TomEE so he knows about the provider/class.

Notice that in this file you set the provider class and how the attributes are set. In fact you set them more or less like a properties file. So when you are are writing address 127.0.0.1, TomEE under the cover will call provider.setAddress("127.0.0.1")

The last thing to do is start using @Resource annotation with MongoDB.

So in this case we are creating a MongoClient provider because TomEE requires a no parameters constructor, but MongoClient has parameters so we need to create a provider class with a method which returns the MongoClient instance to be used.

And what really is awesome about TomEE is that you can even override your @Resource definitions from system properties, so you can do something like:

-Dmongo.address=localhost

where mongo is the id of the resources file and address the name of the field.

So you can change each of the value in an easy way depending on the environment you are pushing. And that's an awesome thing.

So now there is no excuses to not start treating NoSQL databases like SQL databases from the point of view of Java EE.

[Update] Romain notice me that with latest version of Apache TomEE you don't need a default constructor, parameters are bound directly properties as constructor params

We keep learning,

Alex.

Et j’ai sa main!, Jour prospère!, Me voici, Militaire et mari! (Ah mes amis - Gaetano Donizetti)

Music: https://www.youtube.com/watch?v=3aS6M8j3pvQ

martes, febrero 18, 2014

Learn CDI with Apache TomEE [Video tutorials]



In this post I have grouped a collection of videos I recorded some time ago to learn the basic concepts of CDI (Context and Dependency Injection) using Apache TomEE. I suggest clicking the YouTube icon to watch them directly from YouTube site and configure them in HD.

Servlets




CDI (Inject)


CDI (Scopes)


CDI (Name Qualifiers)


CDI (Qualifiers)




CDI (Alternatives)




CDI (Postconstruct)



CDI (Producer)




CDI (Events)




CDI (Interceptors)



CDI (Decorators)




We Keep Learning,
Alex.

Que vas a hacer sin mí, Cuando tú te enteres que you estoy pegao, Con el que sabe no se juega, Y si se juega con cuidado (El Cuchi Cuchi - Mayimbe)