Blogging about Software Development focused on Java Enterprise Edition and Integration. I am also blogging about general Java topics, books and so on.

2016-12-01

Why Value Types Are Important For A Maintainable Software

Some weeks ago I read a tweet which contained this picture and someone said:"That's the reason why Value Types are helpful!". After that I remembered situations happened some years ago and I decided to write a blog post about it.
During some projects I've seen a lot of valdiation code which was quite crazy. Most of the time there were methods with parameters like Doubles, BigDecimals or Strings followed by lots of business validations at the beginning of each method. These business validations were scattered around the whole codebase and most of the time it was copy pasted. These validations contain technical validations like null checks and business validations. Situations like these are really suboptimal for several reasons.
This blogpost describes why you should know and use the concept of Value Types even if you don't do Domain Driven Design.

Why is that bad?

First, code doesn't reflect the business domain. Some of these methods parameters depend on each other and the following validation check in combination with this parameters form a business rule which is really bad placed in terms of a maintainable software. Why? Because the software offers the functionality the Product Owner wants it to have, but it will become very hard to find this specific business rules in the codebase because you can't search for specific nouns the business guy says. I have had this situation more than once. I had to grasp the whole codebase because it was not clear where to find this business rule and which class or method is responsible for that.
On the other hand the semantics are unclear. When using a String instead of a Value Type as method parameter it's much easier to use methods the wrong way which results in implementing bugs. Imagine a method with two parameters of type String. The person who implemented this method knows the responsibilities of each parameter because he implemented this method and knows the internals of this method. Other developers who just want to use this method don't know anything about the internals. They just know the method name and the parameters and they could be unobservant and pass the first String in the second parameter and the second in the first and the code would even compile! Although it's completely wrong from a business point of view! In best case the bug would be detected by a test. Otherwise it could appear at runtime on your local runtime or even worse: in production. When replacing the Strings by meaningful Value Types you can't just switch both parameters without getting compile errors because they are not of the same type. You (as teh developer using this method) can't use the method the wrong way and bring your application in an irregular state.

How to improve it?

To improve this, you simply can implement an immutable class whose constructor contains this method parameter. Within this constructor you can perform all these validation checks you did in the whole code base before. This increases the maintainability of your software.
In the past I often heard people saying:".. but I don't want to create additional classes for just a few lines of code".Yes, it is an additional class, but this class protects you from passing wrong parameters in a method when using Value Types instead of Strings as parameters for example.
In addition to that, bugs will be detected at compile time, already. Value Types could save you a lot of money because you can fix the bug early in the development and not in production.

Conclusion

Value Objects are very powerful when it comes to maintainability of a software. Even if you don't use Domain Driven Design in your projects.
By using Value Objects your code becomes easier to understand and thus easier to maintain for others. It will be easier for other developers to find the business rules the Product Owner is talking about without grasping the whole codebase and searching for usages of different method parameters.

I hope you enjoyed the blogpost and learned something new. If you like it, leave a comment. If not leave one as well ;-)

Bye,
Bennet

Further Readings

  • http://martinfowler.com/bliki/ValueObject.html
  • http://dirkriehle.com/computer-science/research/1998/ubilab-tr-1998-10-1.html
  • http://wiki.c2.com/?ValueObject
  • http://bezmax.com/2015/09/20/clean-code-with-value-objects/
  • https://twitter.com/Heimeshoff/status/799272483853598723

2016-11-18

Building a horizontal JMS Bridge between two WildFly Servers using ActiveMQ Artemis

http://2.bp.blogspot.com/-zNAr0O3xzpU/VK-dALeLNhI/AAAAAAAAACQ/8EDW0gv0Srk/s1600/wildfly_logo_stacked_600px.pngSometimes it's necessary to connect different Message Brokers together. In Enterprise Messaging this scenario is known as Bridging. It can be done with JMS and different protocols like AMQP,  ActiveMQ Artemis core protocol. This blogpost focusses on Bridging with JMS and two Apache ActiveMQ Artemis Brokers running which are running in WildFly. 

https://activemq.apache.org/artemis/images/activemq-logo.pngWhat's a JMS Bridge?

JMS Bridges typically are used to connect Queues and Topics on different brokers or servers. The Bridge forwards messages from a source to a target broker whereas both brokers do not have to be in the same cluster.
That makes bridging suitable for reliably sending messages from one cluster to another, for instance across a WAN, and where the connection may be unreliable. It can also be used for horizontal scaling of Message Brokers like HiveMQ does.

The horizontal Bridging Scenario

There are two different deployment scenarios. In this blogpost I am configuring the Bridge inside a WildFly by using the source Broker. It's also possibile to use an additional ActiveMQ Broker as Bridge which would located in the middle of both Brokers.
The previous picture shows the scenario we want to configure. As you can see we need to configure a Queue on the source Broker, a Queue on the target Broker and we need some configuration to connect both Queues.

Note: I didn't find a better image for devices. Therefore I chose the iPhone image. Feel free to visualize something else ;-)

Configuring the Source Broker

In the first step you have to download and unzip a WildFly server two times for source and target as you can see in the previous picture.
In the next step you have to configure the standalone-full.xml of your source WildFly which is located in the standalone/configuration folder of WildFly.
After opening the XML file you have to add a Source Queue to the Source Broker by adding the following snippet to the standalone-full.xml:
This snippet creates a new JMS Queue with name JMSBridgeSourceQueue. In the next step you have to configure the Bridge. A Bridge has got lots of configuration options like max-batch-time, max-retries and so on. This isn't part of this post.
The next more important configurations to get the Bridge up and running are the source tag which points to the formerly created jms-queue and the target tag which contains configurations for the target queue of the destination broker.
As you can see the target broker needs a authentication.Therefore you need to create a Application User on the target Broker.

Configuring the target Broker

After configuring the source Broker you have to configure the target one. As described before the JMS Bridge requires an Application User which has to be added on the destination Broker and referenced in the source Broker standalone-full.xml file.
This Application User can be created by using the add-user.sh script which is located in the bin folder.
In the last step you also have to configure the standalone-full.xml file of the target Broker.
You have to create a JMS Queue with the same name as the destination of the soure Brokers Bridge configuration. That's it. In the last step you can start both servers and check the logfiles. The Bridge is up and running if both WildFlies start sucessfully without any errors.

Starting the Brokers

./standalone.sh -Djboss.socket.binding.port-offset=100 -c standalone-full.xml
./standalone.sh -c standalone-full.xml

    Conclusion

    A JMS Bridge can be configured with lots of properties. Quality of service, max-batch-time and max-batch-size max-retries and a failure-retry-interval.

    Have fun with your JMS Bridge!

    Bye,
    Bennet

    About Me

    My photo

    Bennet is working as a Software Developer with focus on Java Enterprise Edition. In his free time he is involved in different Java User Group activities, member of JavaLand commitees and blogging about different Java topics.

    Popular Posts

    Proud to be member of

    JUG Hamburg

    Powered by Blogger.