Sunday, February 9, 2014

Micro Services

Micro Services

I was at a session for micro services. There were many sessions covering different aspects of micro services (for seeing of the sessions, have a look at: http://www.meetup.com/full-stack-developer-il/events/155911442). I would like to summarize some of the issues raised and to give my two cents on the topic.
There are many advantages and disadvantages with micro services and there is no silver bullet for all scenarios.  Micro services are a reaction to the big monolithic applications. The biggest disadvantages of monolithic application are the following:
1.       Library bloat: with time as the code base grows, the libraries gets very big and conflicts between shared libraries get harder to handle.
2.       Memory/CPU: a single application uses a lot of memory and cpu and there is no simple way to expand horizontally (except to duplicate the application across machine, and maybe disable portions by configuration files).
3.       Initialization time: the initialization time of the application goes up with each added feature to the application.
4.       Deploy Time: the time to deploy goes up with the size of the application.
5.       Testing: testing become more difficult with big application since it is hard to test only one area without building the whole application memory, and sometimes databases.

Solution overview

Of course for each issue there are other solutions than micro services, but in this blog we will focus on the micro services solution. What is the solution of micro services – very simple. We distribute the main application across multiple processes and machines (hence the name micro service). The client application communicates with the main application (thought there are expansions to micro services were the client will also communicate with multiple servers). The main application will notify to all the micro services of the request and will then return mandatory results to the client. The base framework is an async framework so the main application is not busy with all the logic. The main app only handles the information that is mandatory to return to the client and all other functionality is delegated to services.

Architecture view

The solution for most of these problems, and micro servers as a solution, are on two levels. One is the architectural solution, and the other is on a technical level.
As we mentioned above the communication between services is asynchronous. The standard way to implement this is with a messaging framework (for example: JMS, rabbitmq, ActiveMQ , OpenJMS, Kafka  and more). The design here is that the main application does not even need to know what the services are. Each new functionality that we want to add we can add as a service, and plug it in to the server by registering for events. This is very convenient for application that want to add more processing for information coming in but is not part of the main flow of the application. For instance a purchase on a ecommerce app will enter the request and display to the user the request. Then multiple services will process the information, including checking the inventory and updating if new quantities need to be added. Information about the person purchasing can be added and a lookup for credit history can be done. A full flow of data gathering and processing can be done via different services, and can be added with each. In this example the database is the center of the project, but in other scenarios the data can be pin ponged between services.
Of course if a service needs information from another service in a synchronous way, each service can also have an external API of rest or some other protocol.  

Physical View

The obvious gain from this architecture is that each service can run on any machine in the cloud. As to the issues raised above each service is a separate application so the library is local to each service and will not be big. Each service has its own resources so we will not be blocked by cpu consumption or memory. Deployment is easier since it is on the service level and not the whole application. Also testing is easier since the testing is per service and not on the whole application.
One of the biggest advantage that are pushed with the micro services is the option to totally rewrite a service if the requirements have changed since each service is fairly small, and if a functionality need to be remove the service can just be discarded.
Another big advantage is the language barrier. With micro services you can write each service in any language and with any team. Since all interfaces to the app are via message queue or rest, and language can be used.

Draw backs

But as we know there is no free lunch. What are the major issues that need to be addressed with micro services?
·         Integration: Since there is no app, it is hard to determine ahead of time how the application as a whole will run. The information passed via the message queue might need to change over time, and we do not know which services are using which messages, and which ones need to be updated.
·         Latency: Once logic is distributed across multiple machines there is the latency issue. So only application that the latency is not a big issue can use this architecture.
·         Configuration: How are the configurations of each service handled? Do we have a central repository for configurations? There can be hundreds of machines that need to be configured, and each service with a different format (see https://speakerdeck.com/hagzag/docking-your-services-with-docker for some solutions).
·         Transactions: Once we are in an asynchronous framework that crosses machines we lose the option to have all functionality in one transaction. All “commit/rollback” needs to be done on the application level and not database level.
·         Debugging: How do we debug the application as a whole when each service is on a different machine, in a different language using different logs types.
·         Monitoring: How do we monitor all the applications to make sure they are giving the performance we expect.
For the last two issues see http://zohararad.github.io/presentations/micro-services-monitoring/index.html, solutions for them can be flume, logstash, kibana , sensu.
·         Retransmissions: How do we handle issues where the service fails, we need to make sure that the messaging framework supports transaction of deleting the message only after the service finished with it.

Other solutions?

Are micro services the only solution? As we mentioned above there is no silver bullet. The architecture behind the micro service is an old one of messaging.

OSGI

One architecture that has been around, that also address some of the issues raised above is OSGI (http://en.wikipedia.org/wiki/OSGi).  OSGI focus is to solve library and deployment issues. The basic idea is to generate bundles, where each bundle is a single unit in itself.
The concept was good, but there was never a good implementation of it, and the industry never took it up, since it usually caused more trouble than was worth.

Messaging

The idea of messaging is not new. Using message for transferring data between objects was part of the smalltalk language already in the 80’s (http://en.wikipedia.org/wiki/Smalltalk).
Windows OS used the idea of messaging for handling events from the user in a GUI application (https://developer.mozilla.org/en-US/docs/Web/API/Window.postMessage).
Android OS uses Intents to transfer information between windows and applications. Intents are actually simple messages that are broadcasted and receivers can listen to these intents (http://developer.android.com/reference/android/content/Intent.html).
The basic idea behind messaging is that the data is passed between participants is immutable. This way even with multi-threading there is no memory sharing between with processes that need critical sections.

Spring Integration/ Camel

If you do not want to split your application to multiple services and computer, but you do want to gain the architecture of the micro services, you can use enterprise integration patterns. The basic pattern in every enterprise application is that data needs to pass between processes and needs to be transformed from one presentation to another. In the past we had xslt for xmls, but in object framework we still need to transfer and translate object.
The basic architecture of these frameworks (http://docs.spring.io/spring-integration/reference/html/overview.html, http://camel.apache.org/enterprise-integration-patterns.html) allows each feature to be written in isolation and without any knowledge of the other. The flow between the data is defined in a xml configuration file. The actual process of the messages is the same as queuing where via the xml file you wire the flow of the data, where you can not only pass the data but also transform it for the needs of each feature.

Advantages over micro services

·         You have the flexibility and modularity of micro services without all the maintenance of multiple services and machines.
·         Flow of application can be viewed in xml (and visualized in ide).
·         Spring Integration/Camel support transaction barriers across beans (features).
·         All logging and error handling are handles in one place.
·         Testing can be done on both the feature level and the flow level.

Disadvantages

·         In the case of java, you can only write the code in languages that run on the JVM.
·         There is still an issue of library bloat.
·         Memory / CPU are still issues since you have only one application.
Summary:
Using modular frameworks in a monolithic application give you the architecture advantage of micro services but without the flexibility of horizontal expansion via multiple machines and processes.
See features of spring 4 that help us with micro services: https://spring.io/blog/2013/12/12/announcing-spring-framework-4-0-ga-release.

Akka

Another framework that is between spring integration and micro services is akka (http://akka.io).
In a very simplistic overview, akka is an actor model system (http://en.wikipedia.org/wiki/Actor_model). Akka is written in Scala that is a functional language that brings a functional programing view. Again in a simplistic view Akka is similar to messaging frameworks in that all information that is passed between objects is done by messaging. There are a lot of similarities between akka and spring integration and there are big differences. Since they are different systems they can even be used together.
One big feature in akka that does not exist in spring integration, from the micro service view, is the distribution model. One of the goals of Akka is “location transparency” (http://doc.akka.io/docs/akka/2.2.3/intro/what-is-akka.html). This is one of the big draw backs of spring integration in the micro service perspective. Akka out of the box supports the option to install the system on multiple machines without any code change. So by using akka we can still write in a micro service architecture and gain a lot of the build in features of akka that include transactions (http://doc.akka.io/docs/akka/2.0.1/scala/transactors.html) and the option for horizontal expansion.
The main disadvantage of Akka is that you still have the library bloating as your application grows, and the application is still written as a monolithic application and not a diverse application.
For more information on functional programing and micro services see:







Wednesday, January 22, 2014

Backing up Jenkin Jobs

Backing up Jenkin Jobs


There are plugins that will back you full Jenkins server (https://wiki.jenkins-ci.org/display/JENKINS/Backup+Plugin). But what if in your development team you want to backup only your jobs and add the configuration of each job to your source control.
A simple way to do this is to write a batch file that uses the Jenkins cli. To get the jenkins-cli.jar you need to go to your server at the url: http://build_server/cli/. You should get the following:


You can download the jar from the link on the top of the page.
For each command you can see how to call it.
We will use two commands. The first is to get a list of the jobs you want to backup:
java -jar jenkins-cli.jar -s http://buildevsrv list-jobs abc > jobs.list
This will save the list, filtered by the work “abc” to a file jobs.list.
The for each entry in the file we do the following command:
java -jar jenkins-cli.jar -s http://buildevsrv get-job "job_name" --username %1 --password %2 > job_name.xml
Enter your user name and password (you need permission for configuration of the job). This will save the configuration to your disk. Now you can save it in your source control.

For a full script to get all jobs by a filter:
@echo off
echo getting list of jobs
java -jar jenkins-cli.jar -s http://buildevsrv list-jobs abc > jobs.list
for /f "delims=" %%i in (jobs.list) do (
                if NOT [%1] == [] (
                                echo getting config for: %%i
                                java -jar jenkins-cli.jar -s http://buildevsrv get-job "%%i" --username %1 --password %2 > %%i.xml
                )
)

Don’t forget to pass your username and password to the command.









Wednesday, January 8, 2014

linux autocomplete - maven

One of the very nice feature of linux is the option for auto complete on the command line. Yes windows has the power shell, but it is not the same as linux.
For those in windows and want a linux shell you can install Cygwin (http://www.cygwin.com/).

For those of us that use maven, think of how nice it would be to have auto complete for maven commands.
Well this is possible, have a look at:
http://maven.apache.org/guides/mini/guide-bash-m2-completion.html

If you are using Cygwin then just copy the script to \cygwin64\etc\bash.bashrc

Monday, January 6, 2014

@Configuration vs xml with prototypes

@Configuration vs xml with prototypes


There are two sides to using spring. One is the injection side, and the annotations are  @Autowire, @Inject, @Resource (see http://javaandroidandrest.blogspot.co.il/2013/05/spring-bean-overriding-between-projects.html). The other side is the definition of beans: @Component, @Repository, @Server.

The beginning of spring all injections were done via xml configuration files. With each version spring added more and more annotations so simplify matters.  When it came to injection annotations were usually used and xml files were used only when the annotation was not enough (like using maps).
For configuration files xml were the main default especially when complex configurations were including. One of the more complicated configurations is the prototype.

Prototypes

Before we go into the @Configuration, I would like to add a word on prototypes. In spring there are two scopes one is singleton and the other prototype. Singleton means that only one instance of that bean will exist in the spring context. While prototype means that multiple beans can exist. If you have a multiple singletons (from different types) that reference a prototype bean, each singleton will get its own instance of the prototype.
For example:
@Component
@Scope("prototype")
public class Chair {

}

@Component
public class Garage {

       @Autowired
       Chair chair;
}

@Component
public class House {

       @Autowired
       Chair chair;

}

Anyone that references the house of the garage will get the same instance as everyone else.  Though in the case of the chair both the garage and the house, will each have a separate instance of the chair.
Now when you need to generate during a runtime of the application another instance of the prototype then you need a lookup method.
For example let’s say that during runtime I need to create a new chair, so on my house class I will have a method of: protected Chair createChair();
We cannot create the chair with new Chair(), since then spring will not generate the class, and any injections within the chair class will not happen. So the spring solution to this is to create a lookup method. In the xml you write:
<bean id="house" class="com.domain.House"
       <lookup-method name="createChair" bean="com.domain.Chair" />
</bean>
And in the class you need to add the abstract method
@Component
abstract public class House {

       @Autowired
       Chair chair;

       abstract protected Chair createChair();
}

Spring will then implement this method and any time you call the createChair() a spring instance of the Chair will all injections will be created.

@ Configuration

With spring 3, spring add the @Configuration annotation. What this annotation allows you to do is to actually write all your xml in java code.
So for creating a bean of House we can either add @Component on the house class, we can add to the xml:
<bean id="house" class="com.domain.House"
      
</bean>
Or we can create a class with the annotation of @Configuration to create the bean:
@Configuration
public class ClassFactory {

       @Bean
       public House createHouse(){
              return new House();
       }
}

So for those people that prefer to write java code over xml files, you can now use configuration classes.
You client code still stays the same and you just inject the House using @Autowired.
Of course since the house is a singleton the method of “createHouse” will be called by spring only once and all places that inject the house will get this instance. In the case of prototypes you will add the method of:
       @Bean
       @Scope("prototype")
       public Chair createChair(){
              return new Chair();
       }

Now anytime that you inject a chair to a bean a new instance of the chair will be instantiated.
The configuration class allows you to set any properties that you want on the bean and write any code that you need. The spring framework will do its magic once the runtime finishes the method with the @Bean annotation. For example the method of “afterPropertiesSet” will be called once the @Bean method finishes.
A added advantage to the configuration bean is now you have a built in lookup method for creating prototype beans. Any class that has the @Configuration annotation is also a spring bean, so you can now inject this bean in your class and call the “createChair”. So you can now write in your house class:
@Component
public class House {

       @Autowired
       Chair chair;
      
       @Autowired
       ClassFactory factory;
      
       public Chair createChair(){
              return factory.createChair();
       }

}




Sunday, December 29, 2013

Eclipse – Jenkins

Eclipse – Jenkins


Of course my assumption is that you are practicing continuous integration. If not you should begin with it right away. For more information see http://en.wikipedia.org/wiki/Continuous_integration.
One of the problems with Jenkins is that you need to always open the browser to check what the status of the build is. One of the rules for CI is never commit on a broken build (some even say on a running build), so you need to know the status of the build in a simple an easy way.
Another issue, is once the build is broken you need to click multiple times until you can get the information that you need to fix the build.
Well all this changes with the plugin for eclipse. You can download the plugin from http://marketplace.eclipse.org/content/hudsonjenkins-mylyn-builds-connector#.UsAyivQW1VA, or just search the market place for Jenkins.
This plugin will display the builds that you choose within your eclipse:


The interval for the status checking should be changed since the default is 15 minutes.
A double click on the build will display the tests run, where you can choose to see the console output



On the junit view, you can click on any test, and it will open the code for that test. You can filter the view to see only failed tests or all of them.
A right click on the build will bring you the option to view old build or even to run a new build.
Eclipse even support instant notifications that pop up when a build finished.
Once you install this plugin you will never need to open the Jenkins in your web browser again

Wednesday, December 18, 2013

XML Subsets

XML Subsets

Most applications today use XML for some form of data saving. In testing we also need to validate XML files, find entries in the XML via XPath and search for differences in the XML.
A lot of these abilities can be found in the lib of XMLUnit (http://xmlunit.sourceforge.net/)
This lib knows how to compare XML files, and other actions like:
·         The differences between two pieces of XML
·         The outcome of transforming a piece of XML using XSLT
·         The evaluation of an XPath expression on a piece of XML
·         The validity of a piece of XML
·         Individual nodes in a piece of XML that are exposed by DOM Traversal
One feature that I needed that it did not support is to detect if one XML is a subset of another. For example
I would like to check the following XML is a subset of the next one.
<a>
    <b>
        test b
    </b>
</a>
<a>
    <b>
        test a
    </b>
    <b>
        test b
    </b>
</a>
As you can guess a simple compare will fail since it will compare the first node of b in both XML’s and since the elements are not same it fails. What we need to do is to recursively search all nodes that have the same name and check if they are the same and not to stop on the first. This problem of course is not just on nodes but on attributes as well. If you need this functionally then you can grab the code below:

public class XmlSubsetHelper {
       static private boolean equalNotNullPointers(Object a, Object b) {
              if ((a == null && b != null) || (a != null && b == null)) {
                     return false;
              }
              return true;
       }

       static public boolean isSubset(NamedNodeMap namedNodeMapA,
                     NamedNodeMap namedNodeMapB) {
              if (!equalNotNullPointers(namedNodeMapA, namedNodeMapB)) {
                     return false;
              }
              if ((namedNodeMapA == null && namedNodeMapB == null)) {
                     return true;
              }
              for (int i = 0; i < namedNodeMapA.getLength(); i++) {
                     Node itemA = namedNodeMapA.item(i);
                     Node itemB = namedNodeMapB.getNamedItem(itemA.getNodeName());
                     if (itemB == null) {
                           return false;
                     }
                     if (!itemA.getNodeValue().equals(itemB.getNodeValue())) {
                           return false;
                     }
              }
              return true;

       }

       static public boolean isSubset(NodeList childNodesA, NodeList childNodesB) {
              if (!equalNotNullPointers(childNodesA, childNodesB)) {
                     return false;
              }
              if ((childNodesA == null && childNodesB == null)) {
                     return true;
              }
              for (int a = 0; a < childNodesA.getLength(); a++) {
                     boolean foundMatch = false;
                     Node itemA = childNodesA.item(a);
                     for (int b = 0; b < childNodesB.getLength(); b++) {
                           Node itemB = childNodesB.item(b);
                           if (isSubset(itemA, itemB)) {
                                  foundMatch = true;
                                  break;
                           }
                     }
                     if (!foundMatch) {
                           return false;
                     }
              }
              return true;
       }

       static public boolean isSubset(Node nodeA, Node nodeB) {
              if (!equalNotNullPointers(nodeA, nodeB)) {
                     return false;
              }
              if ((nodeA == null && nodeB == null)) {
                     return true;
              }
              if (!nodeA.getNodeName().equals(nodeB.getNodeName())) {
                     return false;
              }
              if (!isSubset(nodeA.getChildNodes(), nodeB.getChildNodes())) {
                     return false;
              }
              if (!isSubset(nodeA.getAttributes(), nodeB.getAttributes())) {
                     return false;
              }

              return true;
       }

       static public boolean isSubset(Document documentA, Document documentB) {
              if (!documentA.getDocumentElement().getNodeName()
                           .equals(documentB.getDocumentElement().getNodeName())) {
                     return false;
              }
              if (!isSubset(documentA.getDocumentElement(),
                           documentB.getDocumentElement())) {
                     return false;
              }
              return true;
       }

       static public Document parseXML(String xmlSource) {
              try {
                     DocumentBuilderFactory factory = DocumentBuilderFactory
                                  .newInstance();
                     DocumentBuilder builder = factory.newDocumentBuilder();
                     return builder.parse(new InputSource(new StringReader(xmlSource)));
              } catch (Exception e) {
                     throw new RuntimeException(e);
              }
       }

       static public boolean isSubset(String xmlA, String xmlB) {
              try {
                     return isSubset(parseXML(xmlA), parseXML(xmlB));
              } catch (Exception e) {
                     throw new RuntimeException(e);
              }

       }

}

Tuesday, December 3, 2013

Hebrew on the Pebble

Hebrew on the Pebble

There are many new smart watches out in the market. My personal one is the pebble. In my opinion a watch is an extension of the phone, and not a replacement,   and the pebble does just that.
The main disadvantage of the pebble is the SDK environment. There is no simple way to create a pebble application in windows. The workaround for this is a cloud environment that is very nice, you can find it at: https://cloudpebble.net/ide/. In the cloud IDE you upload your resources and write your code. From the cloud you can also compile the application and download it for installation from your phone.
This article will not go into the details of the pebble development. In a broad overview, the pebble GUI is made out of multiple layers that you can create. Each layer can have its own callback so that you can update each layer on a timer that suits you, and only update that layer. There are many API’s for writing text or graphics on each layer so that you can display almost any idea you have.

Language

The main feature that is lacking in my option is the support for multiple languages. Pebble supports only English, and does not support other languages. I am not sure for the reason behind this, it might be since the main market is in the US or the limited memory that the pebble has, or both.
For a review in Hebrew about the watch see: http://www.geektime.co.il/pebble-smartwatch-review/.
The pebble supports two types of applications. Once is a watch face and the other is a watch app. The watch face displays the time in different types of formats and visualizations (a list of watches can be found at http://www.mypebblefaces.com). The watch app is a richer application that usually also interacts with your phone.
If you want to create your own watch face but do not know or want to program, there is a great site that lets you customize your own watch app: http://www.watchface-generator.de/.

Fonts

This blog will deal only with the watch face, and in a future post we will write about watch apps.
What the pebble does support is the usage of True Type Fonts (TTF - http://en.wikipedia.org/wiki/TrueType). The pebble itself comes with some basic fonts and sizes built into the rom (https://developer.getpebble.com/blog/2013/07/24/Using-Pebble-System-Fonts/). You also have the option to add your own custom fonts at the cost of rom location in your app (http://developer.getpebble.com/sdkref/group___fonts.html).

Solution

Once I found this, the rest is as they say history. All I had to do is to use a Hebrew Font, say David, and decide on the font size that I want. I could then display any graphics that I wanted to, and when adding text I needed to use the TTF that I added to my watch. The only disadvantage is that since the pebble does not support RTL you need to write works backwards for it to display correctly.
The pebble has computing capabilities as well, so with a build in math lib, you can easily create a conversion from Gregorian dates to Jewish dates.  Do in addition to a Hebrew clock, you also get the current Hebrew date, and day of the week.

A copy of the watch face I created can be found at:



For the more adventurist people that want to see the code for the pebble have a look at:

More Hebrew watches

Another nice watch that displays in Hebrew words the time can be found at:




A watch that knows how to display the moon phase can be found at: