Hi,
I am trying to understand a situation, when there is a Win-based client application and wants to talk through SOAP/HTTP to a remote J2EE-based application, offering a specific web-service through for example WASP SOAP implementation.
How does this work? Is there any compatibility problem with Win-client written for example in VisualC++ and talking to Java-based SOAP server implementation?
Thanks, Martin

No compatibility problems but you'd have a hard time accessing a web service with VisualC++. The name of the game is C#. If you're bent on C++, you can tackle it somewhat more easily with C++ with Managed Extensions (the new Visual Studio.NET C++ development tool).

How does it work? You're sending and receiving text formatted in XML: it is platform, programming language and transport neutral.

I am facing the same problem. Only unlike our C# friend, I have to work with current business needs that require me to work with Windows-NT. I'm thinking about auto-creating/binding COM API's from a SOAP discription. Its abit like using XML to define the idl, and then generating the COM code to implement the interface, passing calls to and from an awaiting JMS. For implementing this approach, I can either post xml to an awaiting jsp, or use the JMS vendor’s com library.

It all seams to make perfect sense. But I'm a little nerverous about this venture, as I feel that if it is that easy....why can't I find a similar implementation on the web.

I'm seriously considering JIntegra (www.linar.com) to do the leg-work for me. There are several approaches available. The easiest is to use their COM-EJB bridge, (http://www.linar.com/jintegra/doc/javafromcom/weblogic.html). Another way is to generate javabeans that pass calls to the JMS, and using JIntegra to create the DCOM API that I can use on the NT side.

Of course the third means to talking to j2ee that I have considered (for a very brief moment) is using Corba. And why not ? J2ee/ejb support corba. I'm advoiding this route because I don't want to implement the rpc/messaging component, when there are better/more reliable/virtually guarenteed middleware systems out there such as SonicMQ/JIntegra....

I would encourage other responses/views on this matter, as I'm sure there are many of us out there tied to NT on the client side, but wanting J2EE solutions at the server end.

Take a look at this tutorial:
https://www.theserverside.com/resources/article.jsp?l=Systinet-web-services-part-5