Hello, I have some questions about protocols with Tomcat.
I have to develop a server in Java and I am thinking about using Tomcat but the protocol is not HTTP.
How can I use a different protocol than HTTP or AJP ? Should I develop a new connector for Tomcat ?
If you are not using HTTP, it is not clear to me how much use Tomcat will be.
If you can't get Tomcat to generate a ServletRequest by some trick, and turn the resulting ServletResponse into whatever your protocol needs then why bother?
There are plenty of other Java supported protocols already - JMS, email, JINI, etc etc. - what are your requirements?
Joined: Jul 01, 2011
I am going to explain a bit more my request
I have already created a SRU and SRW server with Tomcat and using HTTP.
And now I want to create a Z3950 server but this protocol doesn't use HTTP, my question is how can I change the connector ? Or what layer can I change?
Author and all-around good cowpoke
Joined: Mar 22, 2000
Like I said, if your transport protocol is not HTTP, Tomcat does not have much to offer.
From a casual search, it looks like Z3950 interest groups are trying to adapt to web protocols, are you sure you have to use the old one?
It seems to me that with correct design, you might be able to separate the code that actually deals with Z3950 from the transport protocol.
Tomcat actually handles some protocols other than HTTP or HTTPS, that are JK and AJP.
JK and AJP packets are handled by their connector, so I think it is technically feasible to handle Z3950.
I haven't read so much about the souce files around connectors, but the connector class should be an inheritance of org.apache.coyote.AbstractProtocol.
As William has said, there is work in progress to support Z3950 over HTTP, so unless the exercise is primarily academic or has existing client constraints, that's the first thing I'd look at. Then again, that's what SRU/SRW are, so you've already done that.
Tomcat is first and moremost a servlet container, and while servlets don't actually have to be HTTP servlets, the servlet architecture does impose certain constraints on the protocols it handles.
If you do want a Z3950 server, running native Z3950 protocols, you'd probably not actually get much in the way of sharable code from Tomcat, so it might be simpler and more economical to just implement the server as a stand-alone Java application. Which is what Tomcat itself is, when you get right down to it.
Customer surveys are for companies who didn't pay proper attention to begin with.