Originally posted by Markus Pfeiffer: 4 month ago I already made a XFire Webservice but XFire didnt exist anymore?
It has been moved to Apache CXF (Codehause XFire).
Furthermore someone know if it is possible to present a webservice like this:dotNet webservice
It's unclear what you are asking about.
Do you want your web service to show an asmx extension even though it isn't a .NET web service? Are you trying to make the the web service browser accessible? (See here) [ September 12, 2007: Message edited by: Peer Reynders ]
This is simply something that Visual Studio does when it deploys a web service to the development IIS server. It generates a convenience ASP.NET web page for the web service. For SOAP web services you have to (HTTP) POST the HTTP request (which contains the SOAP Request). IIS looks at the HTTP request and returns a generated web page instead when is sees an (HTTP) GET request to the same URI. The page changes it's appearance based on the query parameters supplied. AFAIK there is no client-side script in the page that invokes the web service from the browser - instead the form parameters are POSTed to the page and the page builds the SOAP request to call the web service on the same IIS instance (which limits its usefulness for diagnosing any remote invocation problems). None of this has anything to do with web services - it is simply a (passing) convenience of the development environment.
In my opinion it�s great for training but of limited usefulness for production code. Believe me, for most properly designed production web services, you do not want to be typing, by hand, in all the information that is necessary issue a request - you want a programmatic test client.
Theoretically this could be done with JSPs but I'm not aware of any tool that does this. If you want to see the SOAP messages that are being exchanged simply use Apache TCPMon.
Furthermore someone tried out webservice and J2ME?
Well, I haven't and I still would have my concerns.
J2ME Web Services (JSR-172) is based on a stripped down (and dated) JAX-RPC 1.1, so you still have the complexity without many of the benefits. XFire on the other hand implements JAX-WS 2.0. So I wouldn't assume that the two can talk to one another.
Given the inherent restrictions of an J2ME client I would consider ditching SOAP entirely (I don't know what your requirements are) and go for (at least) a Plain Old XML (POX) over HTTP or (better) a RESTful web service interface.
You would lose a lot of the code generator support that goes with SOAP, so there will be more hand coding (at least on the client-side), and you'll probably have to learn more about the HTTP protocol - but I think your probability of success will increase dramatically if you choose a RESTful (or POX over HTTP) web service interface for your J2ME clients.