I am in this situation right now. We are frozen in the planning stages of moving a Java monolith toward a micro-service architecture. This seems like a very straight forward understandable approach to help make that happen. I read the article and could easily understand what the tool is trying to do and how it can help.
This is John Davenport at SpectoLabs. We have used AspectJ to create new seams (in Daniel's terms) in Java monoliths that can then be intercepted via http.
It all depends on what sort of bind you find yourself in. Having seen both the Hoverfly approach is far preferable, but one approach may be to use AspectJ, create the seam via http and then intercept using Hoverfly. YMMV.
I'm also looking for more suggestions of how people will want to use Hoverfly with Java projects, and so please do give me a shout via twitter @danielbryantuk if you have any ideas!
One sticking point; what if the monolith does not have an endpoint you can call with an http request? What if you have a client that consumes the back end with server rendered pages and no services are exposed with url endpoints? Do you first have to make the monolith's internal functionality accessible via http requests?
Adding 'seams' into the monolith (and exposing this typically via REST or AMQP) is the most effective way I have found.
The alternative is to 'screen scrape' the data returned from calling the monolithic application via the interface exposed now. For example, calling a website page, parsing the HTML data returned, and extracting what you require. However, the code/algorithms you have to write are typically complicated, and the resultant code often fragile and highly-coupled
