Benefits of a reusable services - SOA is not just bad in concerns of complexity

If you read official magazines or news about programming and architecture then you will come across service-oriented architecture, something that is widely used by big concerns to improve scaleability. Technologies like docker and aws complement each other and make big scaling applications possible. But every technology has its downsides, meaning that it's all about trade-offs. Often the downsides are apparent when talking about complexity. Comparing monolith software with service-oriented software and highlighting the bad things. In terms of open source software there are some interesting benefits to using service-oriented components. Once upon a time...

It was time to check out the brand-new wildfly 10, Java EE 7 and Spring 4, expecting a great experience developing software. To give the complete picture, I'm experienced in old-school spring development and very excited about all the praised features of the big java eap world. In the beginning it was fun to quickly boot an application, add annotations, control database context, inject dependencies and use login modules for different scenarios.

After implementing some authentication and authorization behaviour and a few business-case requirements I was sure that it's a good and fast way to develop an extendable application. I used some basic jsf pages and some services for different requirements. Beside eap development I also wanted to test my logic: creating tests after implementing features and TDD should work too. At this point my experience changed dramatically. Every test I wrote felt very clunky. I'm not talking about isolated business-case behaviour. I'm talking about framework-related behaviour like the Java EE Entity Manager. Did you ever try to insert the entity manager into your tests? You can find helpers like Arquilla for this. And you will realize that all of these helpers rely on a special EAP server versions. If you want to use a new version then you need a new version of your testing framework. In addition, it boots the whole Java EE layer, which is very slow. Spring in this case felt a bit better compared to Java EE but there is still a very complex framework for testing that blew my mind somewhat.

I made a cut and checked out some basic Java frameworks that fitted my needs.

  • Hibernate ORM
  • Hibernate Validation
  • Jersey
  • Jackson
  • Jetty
  • Guice

Every component is flexible, extendable, interchangeable and at least testable, so I created an auth-services that is dependent on the given products. After a few classes I created a basic structure and I was able to use TDD. For fun I used jMockit to get glorious 100% test coverage. It's more for fun than for any real benefit but I was happy about how implementing features felt compared to the previous experience with Spring and Java EE. I know when my software works and when it doesn't and my service boots within 2 seconds.

I'd like to use this authentication and authorization example for a number of projects and want to publish the implementation. After thinking about the problem I realized that it's already possible. By creating services for different categories I can publish my authorization service on github and develop closed source software for my own use as well. So let's think some steps ahead.

There can be some open source services that are well tested and very stable because different groups of people use them:

  • authentication and authorization services
  • file upload/download services
  • caching services
  • comment services
  • payment services
  • communication/messaging services
  • service managers

Each of these can be used and started separately. Your main application containing your business logic can use them very flexibly. For example you can create an ContainerRequestFilter for your jersey service and check for header information. You then contact your authentication service that validates the given credentials. If they accept the authentication then you can let the request pass.

In this case you are very flexible and your scaleability is great. SSO and expensive features are also easy or will just work out of the box if you create multiple applications. It's possible that there are collaboration groups that use the same service and both benefit from working together.

I have heard a lot about service-oriented architecture. But in contrast to the common discussion regarding monolith software vs service-oriented software I concluded that the open source notion is insane compared to common software.

Feel free to check out my repository to add value to existing services or to create services of your own.

Let's work to each other's advantage.

Useful references:

Journerist

Read more posts by this author.