views:

21

answers:

1

How would you modularize a large application that has some incoming (SOAP) webservices, some outgoing webservices, transformations between them and internal formats, internal logging services, accesses external archiving webservices, delays stuff and works on this asynchronously and so forth?

One way is to split the functionality into a collection of WAR, deploy all of them on one application server and have them communicate with internal webservices. This has some overhead, especially if the messages are large, and you might run into performance problems due to thread count restrictions and so forth.

Another way would be to put everything into a giant WAR, such that you can communicate directly. Not exactly modularization. What would you do?

A: 

In my opinion, depends strongly on the dependencies between the modules. Can they live on their own, fullfilling something usefull when running alone? If so, it might make sense to deploy them seperately, so you can upgrade your system while other parts keep running. If they can only do something usefull in combination, the only reason to deploy them on different machines could be limitations of hardware.

Dominik
The modules are not very useful on their own - it takes several of them to serve a request. But I was not necessarily talking about deployment on several machines - the problem how to structure the application also arises on one machine.
hstoerr
But then you would not get a benefit to deploy in different jvms. You just get additional jvms to monitor and have to deal with the dependencies, when you update one module.
Dominik
I did not mean to talk about different jvms, though that would be an option. (I clarified that a little in the question.) We currently use a collection of WARs in a couple of EARs on one Appserver that communicate via internal webservices, but I was wondering whether this is the best thing to do.
hstoerr
If the dependencies of your services are so strong, that they cant live without the others, they are in fact one application. I cant see any benefit in the setup you described. That does not mean, that your code has to be monolithic, since you still can restrict dependencies and limit them to some well defined (internal) APIs.
Dominik