tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <james.t...@eng.sun.com>
Subject Re: config diag, etc
Date Wed, 04 Aug 1999 18:04:35 GMT

costin@dnt.ro wrote:
>
> Ok, I'm totaly lost. One moment someone talks about XML ( a file format),
> then about DOM ( and API for accessing XML files), LDAP( a wire protocol),
> JNDI ( a java API to access any directory service), and so on.

i think we need to be able to discuss different systems dependencies
as all are important. just how important and to who is what i'm
trying to sort out and help come to some sort of consensus on.

i attemped to layer in these, in my eyes, complimentary views in
a 1-pager diagram so that we can kick around the next level details.
i can scrape many of the lines off the picture showing the least
common denominator end-to-end flow with which we can deep dive to
the next round. perhaps that can help.

i personally am not bothered with options and, when my career
decissions depend on it, i want to have more open options then
not ... hence my perspective on designing a general purpose
config service. what does need to happen, though, when options
abound, is to pick the best suited candidates and go with it.

> It would be very usefull to split this discution in 3 subtopics, and
> have separate threads:

i agree what we do need to dive down a bit to flesh out the
details (apis, message formats, etc) for the various entities
at play here. i would hope that we could dive down to the next
level yet keep the bigger picture (and subsequent proto plans)
at an arms length so as to get some parallel activities in
motion.

> 1. What API will be used by Tomcat ( and all other Java Clients of
> Our Config Service). Since tomcat is writen in Java, I guess it's a Java
> API ( and can't be XML :-).

regarding tomcat/xml it is using xml internally today so tomcat
can, for example, request xml constructs from a remote config
service over http and process the data accordingly. in fact, i
can quite likely prototype this implemented as:

	tomcat-http-servlet-configService-xmlData

	which serves up xml txt for the client (tomcat in
	this case) to process

this is really how tomcat is working today with the only
difference being that tomcat does the xml parsing locally
given a url for the config file. that last part should high-light
why it will be trivial for tomcat to request the same data
remotely ... since it wired using urls as source references
be it "file://" or "http://"

also, the rmi piece will be trivial to proto as tomcat is using
rmi to stop the server today. as i see it, we could readily wire
in a dynamic "addContext" rmi hook into tomcat ... that done, i'd
look at doing the same over http/cgi(servlet).

> 2. What API can be used by a non-Java application to access the
> configuration.
> IMHO, at least for Apache the natural way is to use callbacks. It is
> possible to have a mod_config_ldap, mod_config_xml, etc - i.e. Apache can
> access the same config information.
> 
> Is it possible to use the same API in C and Java?

great question. i'd like to add another (well, quite possibly the
same) question:

	is it possible for apache to request configuration data
	over http/s to a config service which may or may not
	be implemented in java?

> 3. What file format do we want to use - and if it is a requirement to have
> a "real" file or we want to support directory services ( not by exporting
> it to a file, and then parsing again the file ) ( and loosing all the
> security, access control, replication, events of a real directory service)
> For file format - XML seems to be the choice.

as i see it, xml can be utilized in at least two places:

	static config data format

	the message format conveyed between the config client
	and the config service

i don't feel that we should necessarily kill ourselves requiring
the specific formats to be identical for these two cases although
there may be beneifits in doing so. for example, there may be some
config processing details which should remain behind at the
config service tier and yet the message format conveyed from the
config service to the config clients could be a translated/transformed
xml format which is more geered to the specific request/transaction
at hand. my suspicions anyway.

hope this helps,

- james

costin@dnt.ro wrote:
> 
> > implementable in other languages, we should first work on a CORBA IDL for
> > the config API, then work out a reference implementation of the API in java.
> > To the reference impl we could add RMI and JNDI hooks that would be outside
> > the scope of the API (which would be the IDL) but put there to hook more
> 
> Ok, I'm totaly lost. One moment someone talks about XML ( a file format),
> then about DOM ( and API for accessing XML files), LDAP( a wire protocol),
> JNDI ( a java API to access any directory service), and so on.
> 
> It would be very usefull to split this discution in 3 subtopics, and
> have separate threads:
> 
> 1. What API will be used by Tomcat ( and all other Java Clients of
> Our Config Service). Since tomcat is writen in Java, I guess it's a Java
> API ( and can't be XML :-).
> 
> - DOM - it's a standard API, but for something else ( i.e. document
> model/manipulation, not configuration/management API )
> 
> - JNDI ( a Java API !) - it's a standard extension and used a lot in Java,
> and it's designed to access hierarchical information, name services and
> directories. Directories services are used by Novel, M$, Cisco, etc to
> _configure_ their products - and JNDI seems to be the Java API for that.
> 
> - Java classes with setXXX() methods ( sort of BeanInfo) ( like in JMX -
> and similar with the way Apache configure modules ): each client will
> define few methods, and the Config Service will call them with the actual
> data. ( in Apache the module define C callbacks which are called by the
> config API when the keyword is read )
> This is the most powerfull aproach - since you can do anything in the
> callback, and the config service is clearly separated.
> ( well, the problem in Apache is that few modules start reading and
> parsing the file by themself )
> 
> 2. What API can be used by a non-Java application to access the
> configuration.
> IMHO, at least for Apache the natural way is to use callbacks. It is
> possible to have a mod_config_ldap, mod_config_xml, etc - i.e. Apache can
> access the same config information.
> 
> Is it possible to use the same API in C and Java?
> 
> 3. What file format do we want to use - and if it is a requirement to have
> a "real" file or we want to support directory services ( not by exporting
> it to a file, and then parsing again the file ) ( and loosing all the
> security, access control, replication, events of a real directory service)
> For file format - XML seems to be the choice.
> 
> I don't understand if directory services will have to export the data in
> XML (?) or not.
> 
> 4. What data structure/model we want to use. That seems to be clear in
> James document, if everyone agree we can clear this item.
> 
> If you read this far, and you think CORBA is the best solution.
> Please take a look at "Management Facilities Architecture" ( 119 pages,
> with IDLs and all ).
> Another aproach would be to use the Naming service ( again, it can speak
> with a directory service or read a flat file - a XML implementation will
> be wellcomed ). (  Corba objects are "configured" using the Naming
> service )
> 
> Costin ( confused )
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Mime
View raw message