I need to develop a webservice that has to process messages containing binary attachments. Not all clients that are going to access this webservice will be written in Java. The webservice will be deployed on Tomcat.

Since the processing of the message can be rather extensive I would like to set up the webservice in an asynchronous matter so that the client doesn't have to wait until the entire process is finished.

What should I use? I've read some articles and tutorials but I didn't get a clear answer about what to use (JAX-RPC, SAAJ, JAXM, ...)

Can anyone give me some guidelines please...

Thx in advance,
Geert

I need to develop a webservice that has to process messages containing binary attachments. Not all clients that are going to access this webservice will be written in Java.

Good so far:)

The webservice will be deployed on Tomcat.

Good luck with this, unless you plan on writing your own SOAP or XML-RPC servlet. You mayt want to utilize a container that has builtin webservices support.

Since the processing of the message can be rather extensive I would like to set up the webservice in an asynchronous matter so that the client doesn't have to wait until the entire process is finished.What should I use? I've read some articles and tutorials but I didn't get a clear answer about what to use (JAX-RPC, SAAJ, JAXM, ...)Can anyone give me some guidelines please...Thx in advance,Geert

The web service should wrap a "service", as in "service" oriented. So when you are designing the actual "service", make that asynchronous. You could use JMS or some other asynchronous framework. Once the "service" is coded and tested, you should put a "web service" in front of it.

You need to design a flexable reusable solution. DO NOT tie yourself to web services. This is very often a mistake made when webservices are a "requirement".

Thank you for your advice.

You're right. It's the actual processing of the message that can be set up in an asynchronous way. The "Web Service" that will be put in front of the actual "service" is just being used to receive the messages and put them in a queue.

What's the alternative for using Tomcat? Will this AXIS framework help me?


Geert

Axis is an implementation of the SOAP API. Whis is valid for webservices. This project, along with tomcat can be used as your web service layer. See: http://ws.apache.org/axis/java/install.html#webapp

If you are using HTTP, which is a safe assumption if you want to use web services, you can post binary 'blobs' using multipart. multipart/form-data, mutipart/mixed will give you the content type and filename, you put them in the content and yank them out using the boundary indicators.

The purpose of the service is to set up a simple system to replicate/archive data.

'Data' can be everything that can be stored on a file system. (images, documents, programs, ...)

The general idea is to send a message containing an XML describing the 'data' and the 'data' itself.

The meta data will be stored in a relational database and the binaries will be put on the file system.

For that kind of data you might consider a straight HTTP-based servlet that handles multipart form data, rather than a web service. You could post the XML meta-data in "form field" items and the data in a "file" item, or you could post an XML file containing both meta-data and the data itself as a single file.

The Apache Jakarta commons FileUpload library might be of help, if you go that route. For transferring large amounts of data, a solution built on HTTP multipart forms might prove more robust than one built on web service RPC calls.

If you do decide to go with a web service, you can use Axis with Tomcat; that works fine. You could also use JBoss.net, which has Axis built-in. It's basically Tomcat and Axis, but there are a few things that make the JBoss.net solution kinda slick (like the hot-deployment of web service archives).