How to refactor common EJB code as a Microservice while refactoring a monolith application

2
votes

I am currently working on a strategy to refactor a Monolith Java/J2EE based application which is running with multiple web services and common EJB code on Weblogic 12c Platform as multiple MicroServices.The common EJB code has session beans which are specific to each web service and it also has common code which is accessed by multiple services.What is the best approach to refactor common EJB code ? Some of the options that I came across are

1.Refactor the common EJB beans as a shared library and deploy it as an EAR - The question here how will the web services lookup the beans (CDI will not work as they are outside the context,Local JNDI lookup is a possibility)

2.Package the common EJB beans as a JAR file and include it all the web services APP-INF/lib directory - This option will create multiple copies of code on various services

Please suggest any other options

2
jakarta-eearchitecturemicroservicesweblogic12cejb-3.1
if you could post a diagram of how things look like... – efekctive
I think you are starting from the wrong end. You should make microservices out of the common code first. – efekctive

2 Answers

1
votes

Splitting a monolith into multiple microservices should result in multiple applications that communicate over the network. So, the microservice's internals are opaque from the other microservices point of view. In this case, the shared/common code should be copy/pasted to any microservice that uses it. This is necessary as it decouples the microservices from each other so they can evolve independently, one of the desired benefits of using a microservices architecture. As an example, in the future you could change the programming language from Java to JavaScript or PHP and nobody will notice.

Read more about this here, at page 33, "DRY and the Perils of Code Reuse in a Microservice World".

0
votes

How about an evolutionary design approach instead of refactoring using your old EJBs?

Indeed many microservice groups take this further by explicitly expecting many services to be scrapped rather than evolved in the longer term.

The Guardian website is a good example of an application that was designed and built as a monolith, but has been evolving in a microservice direction. The monolith still is the core of the website, but they prefer to add new features by building microservices that use the monolith's API.

(From Martin Fowler)