Alex Blewitt wrote:
Speaking in definitions, a Service is a Component that performs an
action (as
opposed to represent a thing like EntityBeans).
Services would include your different J2EE containers, and the
things that
they do.
Surely then it makes it desirable to have a 'Thing' and 'Service'
supertypes to distinguish between them?
I'm not sure what you mean by 'Thing' here, but JSR77 makes a
distinction between a resource and an instance of a resource (a
service). So they have things like a JDBC Driver (a resource) and a
JDBC connection pool (a service). Is that what you mean?
Yes, but I couldn't think up a good word for a non-service class;
resource sounds like it fits the bill. But would then things like
Servlets, EJBs etc be resources as well?
Not necessarily.
A Servlet is active, it *does* something. There is not a one-to-one
relationship with a particular resource and a servlet (unless you are
using JSPs, but it doesn't change the general rule).
With EJBs, there are two types. An EntityBean represents a resource,
or a particular record. It is a "thing". A SessionBean on the other
hand represents encapsulated business logic, or essentially a business
service. So the SessionBean would be a service and an EntityBean would
be a thing.
Keep in mind that one service can use other services to accomplish its
task. Serving up web content is the service that the ServletContainer
supports, but it uses different Servlets to help it accomplish that
task. In turn, those Servlets can use other services (like Cocoon) to
achieve its goal.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
