Hello Philippe,
nice to hear from you. It doesn't matter that you wrote late since I am fully
introduced in heavy work load here at our site, so my contributions to objectweb are
near to zero at the moment. If you would have written earlier, I just would not have
had time to read! ;-)
> 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.
Yes, I recognized that after I wrote my mail and thought over again what I wrote and
what you wrote.
> I think that this is a discussion that must occur at the ObjectWeb
> architecture working group level.
Yes, sure, this is a common topic. Do you think it would have any success to discuss
it?
> 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.
ok
> And we wanted to be able to provide this kind of services in the next
> JOnAS version that will be released.
ok
> This explains why our services are member of org.objectweb.jonas.*
> instead of org.objectweb.*
ok
> 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.
ok
> 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...)
ok
It's good that there is no need to extend this abstract class since it would lead the
intension of the interface-class-paradigm ad absurdum.
> 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.
ok
I just imagined that it would be cool to have a callback to the manager so it could
react to notifications of the server, like e. g. status of server ("about to stop"
etc.).
> 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.
Seems to be quite strange to use a class that is not intended for that usage? I mean,
what does a naming context has to do with the initialization of some component? From
my view, objectweb did a shortcut since all it needs for initialization is already in
a naming context and they did not want to copy that properties into a propietary
structure. :-(
> 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.
ok
> I am not sure to understand the pause method and as we didn't need it
> we have not included it in the interface.
Assume this situation: A service running under Jonas' service manager exclusively
locks a ressource. The administrator of the system now needs to do some
administrational tasks with this ressource. For this, the lock has to vanish. He now
pauses the service, what leads to this specific service unlocks the ressource (maybe
other services do other things but keep lock the ressources; this is up to the
implementor of the pause method). The lock is released, he does what he wants to do
with the ressource, then he fires start agains the service, what leads to the service
now reallocating the lock. At the moment, there is no pause method, what leads to the
administrator having to shut down the service completely. But now think of that
service needs to do very complex checks at shutdown and startup. This checks need lots
of time, so the admin waits and waits and waits. If there would be pause, these checks
maybe could be omitted. This is what I mean. JOnAS - at the moment - has no us!
age of it, but other (f
services would have. One could think of (future version of) JOnAS doing pause by just
dropping all connections but not admin connection; so at restart only connections are
re-allowed, but cache is not dropped meanwhile!
> 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.
I understand that you have a name per service instance in the service manager. But why
does the service itself needs it's name? I mean, in my classic definition of a
service, this process does not need to have interaction with the user, so there is no
need to know it's own name. If UI is needed, the service instance has to use callbacks
(think of my idea of the ServiceContext's init method above) of the context and the
service manager then does the UI; and the service manager knows the name of the
service instance.
> 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.
For current usage this is ok, but if we intend to use the service manager with other
projects this would be a problem in future.
> 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.
ok
> 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 problem is with MultiThreading vs. MultiTasking. Windows and maybe some other OS
runs a VM on one specific CPU. If you have many CPUs, but all services running in the
same VM, this services are all running in the same CPU, so you have no benefit from
adding CPUs. :-( So if you want to have a service running on another CPU (to improve
performance etc.) you need a second VM. The point is: The usage of CPUs is in the
responsibility of the system administrator. In WindowsNT he can assign services to
CPUs. He has full control. But with your design, he has not, since every service can
decide itself, if it starts a new VM or not. This leads to unadministrateability of
the CPUs! This is very bad. To support the administrator, we really should not allow
services to start VMs but only to have a setting in the service manager if a service
should be startet in it's own VM or not.
> 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.
As I wrote above, I would prefer not having that abstract class but only a property in
the service's description, so that the service manager can start the service in a new
VM is this is needed.
> I) we agree with you that the documentation must be more clear about
> dependences between the JOnAS services.
ok
Thank you for your explanations. Now some things are more clear to me. I hope that my
ideas will be remarked since I think that it would be good to have this thing somelike
less proprietary. :-)
Markusjo
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
----
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".
