You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Kimbro Staken <ks...@xmldatabases.org> on 2002/07/19 05:21:54 UTC
Servlet Engine - Opinions
I'd like to hear thoughts on moving Xindice to run under a servlet engine.
I just did some tests with a very simple servlet to start Xindice and I
found that Tomcat was significantly faster then the built in webserver.
The XML:DB API tests run in roughly 18-22 seconds on the old framework and
13-15 seconds under Tomcat. Given this, I'm really itching to finally pull
the trigger on all the code in the server package. We'd end up replacing
about 60 classes with just one or two and get better performance to boot.
I also see significant architectural advantages to this as mentioned in a
previous mail.
The main downside is that things like the CORBA API hang off the old
server framework and wouldn't be able to work anymore. For that I'm
thinking I could just package a shell of the old server which you could
just drop a xindice.jar into and have it work with the latest code. At
some point it will break, but maybe someone will be motivated enough to
pick it up and maintain it as a separate project.
I need to hear other opinions on this. In particular why we shouldn't do
this?
Kimbro Staken
Java and XML Software, Consulting and Writing http://www.xmldatabases.org/
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org
Re: Servlet Engine - Opinions
Posted by Michael Westbay <we...@users.sourceforge.net>.
Staken-san wrote:
> What I was referring to is simply that Xindice has to this point always
> been considered a server. Because of this we need to continue to ship
> something that runs as a server, so we need to pick a mechanism to enable
> that.
So the default installation is embedded and/or a servlet for XML-RPC?
I can +1 that.
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/forum/
Re: Unsubscribed but ..
Posted by "Mark J. Stang" <ma...@earthlink.net>.
Nutan,
You have to go to the Apache web site
http://www.apache.org/foundation/mailinglists.html
Find the list you want to unsubscribe from...
Mark
Nutan Kaul wrote:
> Unsubscribed from this mail list but am still getting mail!Help.
> -Nutan
--
Mark J Stang
System Architect
Cybershop Systems
Unsubscribed but ..
Posted by Nutan Kaul <nk...@mail.arc.nasa.gov>.
Unsubscribed from this mail list but am still getting mail!Help.
-Nutan
Re: Servlet Engine - Opinions
Posted by Heinrich Götzger <go...@gmx.net>.
On Thu, 18 Jul 2002, Kimbro Staken wrote:
>
>On Thursday, July 18, 2002, at 09:37 PM, Michael Westbay wrote:
>>
>> The point I'm trying to make is, my impression is that, with the embedded
>> initiative, Xindice is already headed toward being able to run in a
>> servlet
>> engine if that's where someone wants to run it. That's most likely where
>> I'll run it. But that shouldn't be the only place it may run. (Is that
>> what
>> you're asking by "moving Xindice to run under a servlet engine"?)
>>
>
>What I was referring to is simply that Xindice has to this point always
>been considered a server. Because of this we need to continue to ship
>something that runs as a server, so we need to pick a mechanism to enable
>that. This doesn't in any way limit other ways of running it, in fact it
>should make it quite clear that it is simple to create a custom server if
>you want. The current code is too complex, so complex in fact that most
>people didn't even know that you could run Xindice embedded, or that you
>could run it in another server environment. I'm not exactly sure what
>format we'll ship things in, but we have to ship some form of server and I
>don't want to continue using the current overly complex code to do it.
>This is what I meant, it should be perfectly in agreement with what you're
>saying. At least that is my intention. Also once we update the
>documentation there will be a much greater focus on embedding and general
>flexibility so hopefully it will be clear that there isn't just one way to
>do it. In the past that definitely wasn't clear.
>
>> --
>> Michael Westbay
>> Work: Beacon-IT http://www.beacon-it.co.jp/
>> Home: http://www.seaple.icc.ne.jp/~westbay
>> Commentary: http://www.japanesebaseball.com/forum/
>>
>>
>Kimbro Staken
>Java and XML Software, Consulting and Writing http://www.xmldatabases.org/
>Apache Xindice native XML database http://xml.apache.org/xindice
>XML:DB Initiative http://www.xmldb.org
>
What I would see is some server engine which isn't able to run at its own.
It would need some running environment. This could be either a server bed
to make a standalone server or a servlet bed to have it as a servlet. Or a
embedded bed (if this is even an extra situation) to have it able to run
in some other applications embedded. So people see how to make a bed/proxy
for running the Xindice engine in different environments. For eample command
line interface or connection by CORBA, SOAP, XML-RPC, HTTP or Socket.
This could be seen as a connection plugin or as a running plugin or two
seperate plugins as well.
These plugins are not really part of Xindice itself they exist more like a
demo or example or as some testcases.
Then I could see some authentication, authorisation or accounting plugin
or a simple access plugin.
Sure, these points are issues from xmlBlaster also, but I see lot's of
parallel requirements for both core engines.
People want to connect in many ways. Every user has different
environments. Unfortunately they not all working with Java ;-) (But with
XML, hopefully)
Hope this makes at least some sense to you.
kind regards
Heinrich
--
http://www.xmlBlaster.org
Re: Servlet Engine - Opinions
Posted by Pratik Patel <pr...@ibiblio.org>.
>
>
>Now that Kernel seems to be going away there needs to be some other assembly point for those
>services. JMX would be a great framework for this and you could shutdown, restart and configure
>services in runtime etc.
>
>When running Xindice stand-alone we just start a JMX spine and let it be the server where the
>services start up. When running embedded you just add those services to an existing spine making
>integration with tomcat, Jboss, Weblogic etc. etc. very easy ;). For those servers that are not JMX
>based we provide a way for simple lifecycle administration (start and shutdown) of the stand-alone
>server without calls to System.exit() and the like.
>
In my opinion, JMX is the right way to move things forward. The above
provides a general summary; it should be said that from what I've seen
in the Tomcat 4.1.x releases there seems to be more mbean implementing
classes. Either way, separating the db core from the 'connector' layer,
and making the db core itself an MBean means that it can readily be
deployed into various containers, not just Servlet containers. Think
JMS, for example - how cool would it be store messages on a JMS channel
directly into Xindice!
Perhaps a look at Slide is also in order - they have defined a special
Tomcat SlideHost class:
<Host name="localhost" debug="0" appBase="webapps" unpackWARs="false"
configPath="slide" className="wrappers.catalina.SlideHost">
That they use for dealing with calls to the Slide content management system.
just my $0.02,
Pratik
RE: Servlet Engine - Opinions
Posted by Kevin Ross <Ke...@iVerticalLeap.com>.
My Opinion:
-Change the build process to allow multiple Runtime Adaptations to the
Xindice core. The xindice core should be accessible through a (Xindice)
standard set of interfaces.
1. Default Adaptation: Utilizing a servlet engine
a) Packaged with Tomcat 4.0.4+ (most people will want to
untar, and start it up.
b) Packaged as a separate war so anyone can run it in
the servlet environment of their choice (assuming they don't want
tomcat).
2. Other Adaptations: Whatever anyone else wants to contribute
This gives us the flexibility for an out-of-the-box server, a webapp
plugin, or anything else we can dream up.
-Kevin
-----Original Message-----
From: Per Nyfelt [mailto:per.nyfelt@nordicwave.com]
Sent: Friday, July 19, 2002 8:49 AM
To: xindice-dev@xml.apache.org
Subject: RE: Servlet Engine - Opinions
> What I was referring to is simply that Xindice has to this point
always
> been considered a server. Because of this we need to continue to ship
> something that runs as a server, so we need to pick a mechanism to
enable
> that.
What about describing the Xindice as a set of XML repository services
that can run as a stand-alone
server or imbedded in another server engine such as Tomcat, an EJB
server, etc. ?
Now that Kernel seems to be going away there needs to be some other
assembly point for those
services. JMX would be a great framework for this and you could
shutdown, restart and configure
services in runtime etc.
When running Xindice stand-alone we just start a JMX spine and let it be
the server where the
services start up. When running embedded you just add those services to
an existing spine making
integration with tomcat, Jboss, Weblogic etc. etc. very easy ;). For
those servers that are not JMX
based we provide a way for simple lifecycle administration (start and
shutdown) of the stand-alone
server without calls to System.exit() and the like.
My 2 cents,
Per Nyfelt
RE: Servlet Engine - Opinions
Posted by Per Nyfelt <pe...@nordicwave.com>.
> What I was referring to is simply that Xindice has to this point always
> been considered a server. Because of this we need to continue to ship
> something that runs as a server, so we need to pick a mechanism to enable
> that.
What about describing the Xindice as a set of XML repository services that can run as a stand-alone
server or imbedded in another server engine such as Tomcat, an EJB server, etc. ?
Now that Kernel seems to be going away there needs to be some other assembly point for those
services. JMX would be a great framework for this and you could shutdown, restart and configure
services in runtime etc.
When running Xindice stand-alone we just start a JMX spine and let it be the server where the
services start up. When running embedded you just add those services to an existing spine making
integration with tomcat, Jboss, Weblogic etc. etc. very easy ;). For those servers that are not JMX
based we provide a way for simple lifecycle administration (start and shutdown) of the stand-alone
server without calls to System.exit() and the like.
My 2 cents,
Per Nyfelt
Re: Servlet Engine - Opinions
Posted by Kimbro Staken <ks...@xmldatabases.org>.
On Thursday, July 18, 2002, at 09:37 PM, Michael Westbay wrote:
>
> The point I'm trying to make is, my impression is that, with the embedded
> initiative, Xindice is already headed toward being able to run in a
> servlet
> engine if that's where someone wants to run it. That's most likely where
> I'll run it. But that shouldn't be the only place it may run. (Is that
> what
> you're asking by "moving Xindice to run under a servlet engine"?)
>
What I was referring to is simply that Xindice has to this point always
been considered a server. Because of this we need to continue to ship
something that runs as a server, so we need to pick a mechanism to enable
that. This doesn't in any way limit other ways of running it, in fact it
should make it quite clear that it is simple to create a custom server if
you want. The current code is too complex, so complex in fact that most
people didn't even know that you could run Xindice embedded, or that you
could run it in another server environment. I'm not exactly sure what
format we'll ship things in, but we have to ship some form of server and I
don't want to continue using the current overly complex code to do it.
This is what I meant, it should be perfectly in agreement with what you're
saying. At least that is my intention. Also once we update the
documentation there will be a much greater focus on embedding and general
flexibility so hopefully it will be clear that there isn't just one way to
do it. In the past that definitely wasn't clear.
> --
> Michael Westbay
> Work: Beacon-IT http://www.beacon-it.co.jp/
> Home: http://www.seaple.icc.ne.jp/~westbay
> Commentary: http://www.japanesebaseball.com/forum/
>
>
Kimbro Staken
Java and XML Software, Consulting and Writing http://www.xmldatabases.org/
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org
Re: Servlet Engine - Opinions
Posted by Michael Westbay <we...@users.sourceforge.net>.
Staken-san wrote:
> I'd like to hear thoughts on moving Xindice to run under a servlet engine.
> [...]
>
> The main downside is that things like the CORBA API hang off the old
> server framework and wouldn't be able to work anymore.
I've been lurking for quite a while. I think it's great that you've been
working hard at cleaning everything up recently. Nonetheless, let's step
back and look at what is happening.
1. The basic Xindice server will be a stand-alone (embedded) version
with a set of interfaces to access and manipulate data.
2. Add-on protocols (which fire up factories) may be implemented to
handle accessing data remotely - allowing for RMI, SOAP, CORBA,
and other RPC-type binding mechanisms.
Please correct me if any of this is wrong.
If the above is accurate, I can see several possible servlet container uses:
1. A class that exposes the interface and runs embedded as an Apache Axis
web service (Xindice is in the same VM as the application server).
2. A class that exposes the interface and has some additional configura-
tion parameters to specify where to locate Xindice (protocol, server,
etc.)
3. A custom application that uses it, either embedded or with one of
the add-on protocols.
You said in a previous message that you wanted to be able to focus on the main
database engine, not all of this connectivity stuff. That seems to me to be
what the embedded team is working on. Once the default embedded protocol is
set, other protocols can be added on without any interference with the core
database. These different protocols, like JDBC, can be totally independent
of the main database work (although some sort of RMI implementation would
probably come standard along with embedded to allow the xindice command line
tool to work).
An Axis SOAP interface would then become an optional separate or sub-project.
The CORBA interface would become an optional separate or sub-project. Those
who don't need a CORBA listener won't build and/or run it.
The point I'm trying to make is, my impression is that, with the embedded
initiative, Xindice is already headed toward being able to run in a servlet
engine if that's where someone wants to run it. That's most likely where
I'll run it. But that shouldn't be the only place it may run. (Is that what
you're asking by "moving Xindice to run under a servlet engine"?)
--
Michael Westbay
Work: Beacon-IT http://www.beacon-it.co.jp/
Home: http://www.seaple.icc.ne.jp/~westbay
Commentary: http://www.japanesebaseball.com/forum/
RE: Servlet Engine - Opinions
Posted by Matt Liotta <ml...@r337.com>.
Pull the trigger!
Matt Liotta
President & CEO
Montara Software, Inc.
http://www.montarasoftware.com/
V: 415-577-8070
F: 415-341-8906
P: 4155778070@messaging.sprintpcs.com
> -----Original Message-----
> From: Kimbro Staken [mailto:kstaken@xmldatabases.org]
> Sent: Thursday, July 18, 2002 8:22 PM
> To: xindice-dev@xml.apache.org
> Subject: Servlet Engine - Opinions
>
> I'd like to hear thoughts on moving Xindice to run under a servlet
engine.
> I just did some tests with a very simple servlet to start Xindice
and I
> found that Tomcat was significantly faster then the built in
webserver.
> The XML:DB API tests run in roughly 18-22 seconds on the old framework
and
> 13-15 seconds under Tomcat. Given this, I'm really itching to finally
pull
> the trigger on all the code in the server package. We'd end up
replacing
> about 60 classes with just one or two and get better performance to
boot.
> I also see significant architectural advantages to this as mentioned
in a
> previous mail.
>
> The main downside is that things like the CORBA API hang off the old
> server framework and wouldn't be able to work anymore. For that I'm
> thinking I could just package a shell of the old server which you
could
> just drop a xindice.jar into and have it work with the latest code. At
> some point it will break, but maybe someone will be motivated enough
to
> pick it up and maintain it as a separate project.
>
> I need to hear other opinions on this. In particular why we shouldn't
do
> this?
>
> Kimbro Staken
> Java and XML Software, Consulting and Writing
http://www.xmldatabases.org/
> Apache Xindice native XML database http://xml.apache.org/xindice
> XML:DB Initiative http://www.xmldb.org