Hi Markus,
Better late than never!
I respond only today to your mail about JOnAS services,
It was so dense and I wanted to discuss with all the members of the
JOnAS team.
Thank you for having studied precisely our documentation and
implementation and thank you very much for your feed back which is very
valuable for us.
A) To begin with, I want to say that there is a main difference between
your approach and our that is that our goal was not to define a general
services architecture as the Java Platform Service Layer you are
proposing.
I think that this is a discussion that must occur at the ObjectWeb
architecture working group level.
All we wanted to do was to extend the existing JOnAS service notion and
to define new services that can be defined outside JOnAS but launched by
JOnAS.
And we wanted to be able to provide this kind of services in the next
JOnAS version that will be released.
This explains why our services are member of org.objectweb.jonas.*
instead of org.objectweb.*
But, we agree with you when you say that sm is not a clear topic and we
have changed for a org.objectweb.jonas.service package.
B) Our documentation seems to say that the implementor must
extend the AbsServiceImpl, in fact the service provider is not obliged
to use this AbsServiceImpl and he may implement the Service interface.
I agree with you that this AbsServiceImpl must be kept internal for the
use of JOnAS services and we must tell that the service provider must
implment
the Service interface. (So the doX methods are not seen anymore...)
C) The Context that is used in the init method is not a callback to
give
information from the service back to service manager, in fact this
context is
only used for passing configuration information to the service.
Jndi Naming Context versus Properties: the choice of Naming Contexts
have been made within the ObjectWeb consortium, as a way to unify the
ObjectWeb component initialization.
D) For the definition of the Service interface, I think it is a first
version and we wanted it simple (start/stop). The reason why there is an
init
method
is that we think that in the future it will be possible to defer the
starting of a service. So we have to make difference between init where
the
service must be initialized (this is at the server run time) and start
that
can occurs later. I agree with you that for the moment init and start
are executed sequentially.
I am not sure to understand the pause method and as we didn't need it
we have not included it in the interface.
E) Why we need a name for a service? this name is only needed by the
Service Manager for indentifying services. For the moment there is only
one case where a service can use this name, it is when a service want to
get a
reference to another service.
This name may be used also in traces if for example there are multiple
instances of the same service running.
F) We have choosen to put all the properties in the jonas.properties
file because as I said earlier for us we are handling only jonas
services.
The second reason is that we wanted to make the installation and
configuration of JOnAS easier. I think it is simpler to deal with only
one
properties file than multiple properties files.
G) dbm service is for managing resources that are JDBC DataSource. We
have the jms service for the JMS resources, and in the next release we
will
have the resource service that will manage resources compliant to the
J2ee
Connector Architecture Specification (version 1.0). With this resource
service it
will be possible to access JDBC DataSource resource if you have a
Resource
Adapter JDBC (Objectweb will provide this kind of RA).
Furthermore note that the support for pluggability of JMS providers into
an application server will be added in the future versions of
specification.
So we think it is better to wait before to unify all services related
to resources as you are suggesting to do.
H) Currently the Service Manager doesn't start a single thread for each
every service. I am not sure that creating a thread/service will improve
performances. It is up to the Service provider to create or not a new
thread
when the service starts.
The class AbsDynamicServiceImpl is currently not used in JOnAS. We have
kept it when we have merged with the contribution of our partner
Libelis.
I am not sure that we must keep it and I think we don't have to speak
about
dynamic services in the documentation.
I) we agree with you that the documentation must be more clear about
dependences between the JOnAS services.
Best regards,
--
Philippe
Philippe Coq Evidian Phone: (33) 04 76 29 78 49
Bull S.A - 1 rue de Provence - 38432 Echirolles Cedex France
Download our EJBServer at http://www.objectweb.org
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
