4

I am confronted with the problem of migrating a huge monolithic java web application towards a more service oriented approach. The application has grown for years from what it was originally desinged for and is still growing. That means a lot of changed customer requriements where development under time pressure with few concernce about code quality. That led to very very complex code structure (no modular packaging, a lot of complex inheritants, mix of functionality in classes and as good as no documentation).

Now step by step funcionality shall be extracted and run as service.

Replacement/Redevelopment is currently out of questions. So the code should be extraced and wrapped so it can be replaced later with a new cleaner version.

The problem I now have to deal with is that it is really hard to identify the code that represents a functionality and extracting it without breaking other functionalities or even the whole application.

Any ideas how I can approach this problem? I am open to everything.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
Tarken
  • 141
  • 3
  • 4
    [Working Effectively with Legacy Code](http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052) – Oded Aug 22 '12 at 09:50
  • thx using unit tests to see if functionality broke is a good idea. – Tarken Aug 22 '12 at 11:32

3 Answers3

6

Thoroughly construct and define an API, or set of different APIs if needed, then implement by just wrapping requests to this webapp (and/or packages which are used by this webapp).

This will help you to "multithread" following development. You'll be able both build new tools, which will use your new API, and, at the same time, you can start gradually change API implementation, thus getting rid from old webapp.

Divide and conquer, nothing has changed since Romans :)

shabunc
  • 2,424
  • 2
  • 20
  • 27
  • Thx, thats what I am hoping to achieve. The problem here is identifing the dependencies to create usefull API's – Tarken Aug 22 '12 at 11:34
3

The main way to achieve this is by first identifying shearing layers - those parts that seems slightly less firmly embedded in the rest of the app. For example, DB access - every bit of that calls an external system, so its an ideal place to look for replacing with SOA calls.

Next you can look at larger areas that are more modular, and replace those with an external SOA call. You're basically splitting up the monolithic code as best you can into chunks that are accessed via a SOA rather than an ordinary method call. You may need to ensure that some of the replaced modules are wrapped in classes that look like the old so the rest of the old app doesn't know anything's changed - just that the internals are now calling an external system rather than internal code.

Once you've got all that done, you'll have a smaller codebase, but it'll still be messy and monolithic. At that point, you have to really get dirty and change the way the code works, you'll need to start changing the GUI or the bulk of it in more intrusive ways, take a part that is on the edge of the main program and start there, once you've done a few of those it'll become easier.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
0

You have to create an API that exposes methods than can be made into SOAP services.

Other apps can use your functionality.

Your current app can continue to exist although I'd recommend to refactor it to call the API functions ( no SOA necessary here ).

SOA is for sharing useful business logic between applications. But it doesn't mean that the app that originated the bussiness logic has to use SOA to use it's own business logic. That app could use SOA to consume others' bussiness logic.

Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154