The ideal Web Service Project Structure, what is it exactly? I can't even count the number of web services that I have put together over the years. I have done them with so many different languages and technologies (Java, Python, C++, SOAP, REST, XML, JSON, WebSphere, JBoss, Jersey, Spring, Django, etc…) that I just can't keep track. However, there is one thing that always seems to happen with each team project. There is a long, drawn out debate about how the Web Service Project Structure should be defined and structured. I am truly baffled by this endless debate. Web services are not a new thing. Software engineers have been building web services for quite a while, and everything has been pretty much figured out by very smart people. Fortunately for me, I have had the privilege of working with some of those smart people.
Starting with the basics of the Web Service Project Structure, there will be a client and a server. The client will submit requests, get back the response and then let some other application do something meaningful. The client could be used in more than one place, because different applications could need to use the web service.
On the other side, the server will answer requests, process the requests, and return responses. Clearly, from this brief discussion, client and the server should really be two separate artifacts, a client and a server. The server artifact would be deployed onto an application server. Thus, the server should be in its own project, and the client should be in a completely different project. Avoid the temptation to put them both in the same project. This would make the client and the server physically dependent upon each other, which violates the principle of decoupling, and will just lead to a whole bunch of avoidable problems.
The next question and point of debate in the Web Service Project Structure is the models, exceptions, constants, etc… This is a fair question, because you really want to be able to share these files with both the client and the server. For instance, with the model objects, the server will need to populate them with some information and return them. The client then needs to receive those same model objects and pass them on to the application that needs them. A similar situation would hold true for the exceptions, constants, etc… This can be solved with a third project.
The additional project in the Web Server Project Structure would be used to contain these common dependencies. Actually, you may even consider using two separate projects, but that is really where personal preference starts to kick in. Either way, you would put all the files that are needed by both the client and the server in the other project, and then make the common project a dependency for both the client and the server. The good thing about the common project is that it will not change much once the initial development has been completed.
The diagram below provides a conceptual model of how the different projects should be structured, and how the dependencies will need to be mapped.