4

We have multiple web apps on our container (Tomcat) that don't interact with each other but they share the same data model. Some basic data access operations are used in multiple web apps, and of course we don't want the same code duplicated between multiple webapps.

For this case is it better to build a library to provide the common functions or to expose the functions as a web service?

With the library the user would have to provide the data source to access the database while the web service would be self-contained plus have its own logging.

My quesion is similar to this SO question but performance isn't a concern - I think working with a web service on the same container will more than meet our needs. I'm interested to know if there's a standard way to approach this problem and if one way is better than the other - I'm sure I haven't considered all the factors.

Thank you.

Community
  • 1
  • 1
Paul
  • 19,704
  • 14
  • 78
  • 96

3 Answers3

3

I would make them a library. This will reduce any performance hits you would incur from network traffic, and in general would make it easier to reach your applications (because your library can't go 'down' like a webserver). If your applications which use this library otherwise do not require a network connection, then you will be able to totally relieve yourself of network connectivity constraints.

If you think you may want to expose some functionality of this library to your users, you should consider making a webservice around this library.

nicholas.hauschild
  • 42,483
  • 9
  • 127
  • 120
  • 1
    +1 - Its easy enough to make it a web-service later. Whether or not to expose as a web-service depends on organizational and operational constraints and goals. – nsfyn55 Sep 22 '11 at 13:51
  • Although this is true, OP specified that performance is not a concern. – Janac Meena Jan 07 '19 at 15:15
1

If it is just a model with some non-persistent operations (non-side effect calculations, etc) I'll use jar library. If it is more like a service (DB/Network/... operations), I'll create a separate webservice. If you have strong performance requirements, local library is the only solution. Also you can implement it using interfaces and change implementation when it will be clear, what to use.

dbf
  • 6,399
  • 2
  • 38
  • 65
  • Given the history of this project I was leaning towards web services anyway. This answer to another question lays it out in the same way you did: http://stackoverflow.com/questions/1312825/web-service-vs-shared-library/5958742#5958742 – Paul Sep 22 '11 at 16:17
0

Webservice will certainly have its own share of overhead, both in terms of cpu and the codebase. If you dont to duplicate the same jar in every project, you can consider moving it to server lib, so that once updated every webapp gets the change. But this approach has a major drawback too, suppose you make some non backward compatible change in the model jar and update one webapp to use the newer model, you will certainly have to update all other webapps to be able to adapt to changes made in the common jar. You cant run multiple version from same server lib. You can package appropriate version of common jar in every webapp, but then for even a minor change in the common (model) jar, you will have to repckage and deploy all the webapps.

kdabir
  • 9,623
  • 3
  • 43
  • 45