Web Service Implementation Heavily Based on The Singleton Pattern

Question

Dear all
I have recently joined a project that is 2/3 through development of a medium sized application providing synchronous and asynchronous implementations for a number of Use Cases exposed as Web Services. The design is one that I have not come across before and am keen to understand.
Web Service calls enter the application through a singleton, which in other respects is a POJO. This class manages a number of instance variable references to other classes responsible for implementing each Web Service method, including data access using Hibernate. Since the top level singleton class is, well, a singleton, I understand this to mean that all of the other classes maintained as instance variables will themselves only ever have one object instantiated (assuming of course that no other thread of execution instantiates them except our singleton WS entry point). To my way of thinking this turns the whole of the Web Service implementation into a kind of singleton application. This strikes me as a procedural programming idiom that happens to be implemented using Java, since Objects with state are not being used. I have not yet asked the question "why?" of my new colleagues but I would like to ask you what the consequences of this design are likely to be. Particularly considering that this application will be expected to handle concurrent servicing of Web Service requests - and so be thread-safe. Can it be thread safe? Are there likely performance implications? Forgive my ignorance is what I describe known as a Singleton Web Service?
Regards
David

Answer 1

Web Service calls enter the application through a
singleton, which in other respects is a POJO. I'm confused about this sentence. Is the application somehow separate from the web service? Is the application acting as a service to this web service? How is the application being hosted? Does it run in a container as well?
This
class manages a number of instance variable
references to other classes responsible for
implementing each Web Service method, including data
access using Hibernate. If all the references are stateless, preferably interfaced-based, you aren't likely to have thread issues.
Since the top level
singleton class is, well, a singleton, I understand
this to mean that all of the other classes maintained
as instance variables will themselves only ever have
one object instantiated (assuming of course that no
other thread of execution instantiates them except
our singleton WS entry point). To my way of thinking
this turns the whole of the Web Service
implementation into a kind of singleton application.You keep using web service and application. Are we just talking about a web service implementation here?
This strikes me as a procedural programming idiom
that happens to be implemented using Java, since
Objects with state are not being used. You are correct, sir. If services are stateless, and they should be, then they aren't exactly rich objects with state and behavior. It's very procedural, indeed.
I have not
yet asked the question "why?" of my new colleagues
but I would like to ask you what the consequences of
this design are likely to be. Particularly
considering that this application will be expected
to handle concurrent servicing of Web Service
requests - and so be thread-safe. Can it be thread
safe? If the web service is indeed stateless, then it should be thread-safe.
Are there likely performance implications?Maybe. Best to measure if those arise to see if the web service is the cause.
Forgive my ignorance is what I describe known as a
Singleton Web Service?I don't know if it's been given a pattern name. If it's a Singleton, then that's true. If it's a service, that applies. If it's deployed on the web, I'd say the label fits.
%