Application Scoped Object in Web Service

[Matt]

Hello,

I'm an experienced C# dev working on a new project in Java (haven't
touched it since college) and was wondering if I could get some input
on my design. I have a search engine object that will take a non-
trivial amount of time to instantiate and that I need to be exposed
via a web service - it will be a singleton, so that every web service
request will be serviced by it rather than having the overhead of
instantiating a new search engine object with each call.

In C#, I would typically create a Windows service backend that would
host the singleton object and then hook the web service up via .NET
remoting over a TCP binary channel. This has worked great in the past,
but being new to Java I was wondering if there is a better solution to
my problem available in this camp. In Java, I am currently building a
backend service/daemon that will host the singleton and expose it to
the web service via RMI... basically the same pattern with different
libraries.

I've come across mentions of Application-Scoped objects in Axis web
services, could I utilize this for my singleton object and do away
with the service/daemon backend application completely? What are the
pros and cons to doing this? Is it reasonable to host a java
application like this within a webserver process? This is production
code that will be shrinkwrapped and shipped, so it has to work well
and reliably.

Thanks for your time,
Matt

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I'm an experienced C# dev working on a new project in Java (haven't
touched it since college) and was wondering if I could get some input
on my design. I have a search engine object that will take a non-
trivial amount of time to instantiate and that I need to be exposed
via a web service - it will be a singleton, so that every web service
request will be serviced by it rather than having the overhead of
instantiating a new search engine object with each call.

In C#, I would typically create a Windows service backend that would
host the singleton object and then hook the web service up via .NET
remoting over a TCP binary channel. This has worked great in the past,
but being new to Java I was wondering if there is a better solution to
my problem available in this camp. In Java, I am currently building a
backend service/daemon that will host the singleton and expose it to
the web service via RMI... basically the same pattern with different
libraries.

I've come across mentions of Application-Scoped objects in Axis web
services, could I utilize this for my singleton object and do away
with the service/daemon backend application completely? What are the
pros and cons to doing this? Is it reasonable to host a java
application like this within a webserver process? This is production
code that will be shrinkwrapped and shipped, so it has to work well
and reliably.

Why not just have the singleton in the servlet container and
load it with a startup servlet ?

Axis application scope is for the web service itself. A session
or request scope web service can access a singleton fine.

I would use a singleton in .NET as well and initialize in
Application_Start and keep it in process with the web service.

Arne

 

[Mike Schilling]

Hello,

I'm an experienced C# dev working on a new project in Java (haven't
touched it since college) and was wondering if I could get some input
on my design. I have a search engine object that will take a non-
trivial amount of time to instantiate and that I need to be exposed
via a web service - it will be a singleton, so that every web service
request will be serviced by it rather than having the overhead of
instantiating a new search engine object with each call.

In C#, I would typically create a Windows service backend that would
host the singleton object and then hook the web service up via .NET
remoting over a TCP binary channel. This has worked great in the past,
but being new to Java I was wondering if there is a better solution to
my problem available in this camp. In Java, I am currently building a
backend service/daemon that will host the singleton and expose it to
the web service via RMI... basically the same pattern with different
libraries.

Perhaps I'm missing something, but why not co-locate the seatrch engine with
the web service? Create it in Servlet.init() and dispose of it in
Servlet.destroy(); (As far as I know, there's no equivalent of
Servlet.init() in .NET; it allows you to perform initiialization when the
container starts up, as opposed to when the first request is received.)

 

[Lew]

Perhaps I'm missing something, but why not co-locate the seatrch engine with
the web service? Create it in Servlet.init() and dispose of it in
Servlet.destroy(); (As far as I know, there's no equivalent of
Servlet.init() in .NET; it allows you to perform initiialization when the
container starts up, as opposed to when the first request is received.)

Nit: The init() method is not called when the container starts up,
necessarily, but

... by the servlet container to indicate to a servlet that the servlet is being placed into service.

For non-single-instance servlets, that could be multiple times as I read the
Javadocs.

 

[Mike Schilling]

Nit: The init() method is not called when the container starts up,
necessarily, but

Right. I was assuming that the servlet would be started at container
startup, but this is a per-servlet configuration option.

For non-single-instance servlets, that could be multiple times as I
read the Javadocs.

That's true. This is an unusual case, though; servlets can have multiple
instances only if they implement SingleThreadModel, and that's deprecated in
Servlet 2.4.

 

[Lew]

... servlets can have multiple
instances only if they implement SingleThreadModel, and that's deprecated in
Servlet 2.4.

Rrr? I thought it was up to the servlet container how many instances it fires up.

 

[Mike Schilling]

Rrr? I thought it was up to the servlet container how many instances
it fires up.

Not acording to the spec. See
http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html, where you
can download it; I can't find it online.