Web Service Implementation Heavily Based on The Singleton Pattern
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
[1595 byte] By [
mangofirea] at [2007-11-27 10:38:35]
# 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.
%
