Discussions

XML & Web services: How do clients produce SOAP ?

  1. How do clients produce SOAP ? (7 messages)

    I do not understand the architectural pieces involved in how clients are producing the SOAP needed for consumption. What are some of the ways people are doing this for different clients:
    for Browsers?
    for PDA?
    for server clients?
    for cell phones?

    Threaded Messages (7)

  2. One way might be to apply an XSLT to the WSDL to generate the SOAP for a request.

    Of course, another way is to parse the WSDL and apply and use the schema to generate the XML in memory.

    The XSLT approach might be slower.

    Either way, this is not an undertaking to be taken lightly. Generating soap requires a very good understanding of the WSDL and SOAP schemas. Most people would not want to embark on this adventure at all.

    I'm assuming you asked the question because you are looking for client side tools that help you do this. For PDAs and cell phones, I do not know any tools unless Sun has something. For Browsers, there is a "tool" that generates SOAP in Javascript (perhaps it is CapeConnect). For Server clients of course there is no dearth of tools.
  3. Let me rephrase the question:
    What does the browser send out, when does it become SOAP, and how is this done with a homegrown gui instead of a browser?
  4. How do clients produce SOAP ?[ Go to top ]

    Jonathan,

    There are two things to a SOAP message. The SOAP message it-self and the transmission protocol, along which it is passed around. i understand or assume in ur case its HTTP.

    u need to at least construct the SOAP message. a typical browser sends out a HTTP request, now u can pass of ur SOAP message either part of HTTP body or post/get request. and thats what basically is a SOAP request over HTTP protocol.

    does the above explanation answer, "when does it become SOAP"

    now how do u emulate a browers behaviour with ur own GUI. well as i mentioned earlier there r two parts. one is to set up a HTTP connection, which will act as a transmission protocol. that can either be done using raw sockets or u can use HTTP connection utils(java.net.*). once u have resolved the connection part, next is sending the actual SOAP request. there r various ways, some of them were mentioned above. u can also take a look at JAXM. (JAVA api for XML messaging). it should answer all ur questions. it will let u construct the raw SOAP request and also connect to the SOAP service end-point and then get the results back.

    sun also has a reference implemenation which u can try it out.

    hope this helps, lemme know




  5. How do clients produce SOAP ?[ Go to top ]

    Kapil, you write:
    "u need to at least construct the SOAP message. a typical browser sends out a HTTP request, now u can pass of ur SOAP message either part of HTTP body or post/get request. and thats what basically is a SOAP request over HTTP protocol."

    You still did not explain how a browser's name value pairs became a SOAP message. Forgetting the javascript option for a second, will I have to change name/value pairs into SOAP on the server?
  6. How do clients produce SOAP ?[ Go to top ]

    Jonathan,

    I really could not understand what u mean by "name-value" pair.

    All i can say is that a client(web service consumer) who needs to call on to web service, listening for SOAP messages, has to construct a SOAP message request. Theres no magic to it, u have to create a SOAP message request. the browser doesnt do it for u.

    if by name-value pairs u mean, ur data parameters u sending to ur servlet/jsp then yes u will have to represent these name-value pairs as a SOAP request and then send this SOAP request to web service listening for SOAP request. the browser wont do it for u. niether wud the web service unless u write some specific code ot do that for u.

    drop in a mail, incase u have some more question or post it write here -

    kapil_israni@yahoo.com
  7. The browser's key/value pairs aren't really part of an HTTP transmission, they're carried IN the transmission as data, just as your SOAP packet will be. For instance when your web browser sends a URL to Google like, http://www.google.com/search?sourceid=navclient&querytime=-ZMXjB&q=java+development, everything in the URL after the http://www.google.com/search? is called the query string. In Google's case the query string is sent using the GET method. If you look in your HTML forms you will see that you have a METHOD attribute of your <form> tag, this informs the browser of how the data is to be sent. The thing to realize about the query string is that is just sent as one big string, HTTP itself does not represent it as key/value pairs. so an HTTP transmission could look like this:

    HTTP 1.1
    GET /search
    BODY ?sourceid=navclient&querytime=-ZMXjB&q=java+development

    Once the server receives this request it can break the BODY down into key=value pairs and exposing them to your code as key/value pair constructs. The confusing thing about all of this is that html makes it very easy to construct these query strings but doesn't really give you access to the raw HTTP requests to insert your xml into. So by using a browser to send your SOAP packets you would just include the SOAP as a key/value pair, very ugly but quick and easy, doing something like this:

    <form action="HTTP://mywebservice/soaphandler" method="post">
    <!-- use post because you can send more data that way -->
    <input type=hidden name="SOAP-REQ" value="$(SOAP-STUFF)">
    </form>

    Now that is really dirty and should be recommended against, I would use a servlet that would parse regular key-value pairs sent from the browser into SOAP requests and forward it to the web service.

    HTTP 1.1
    GET /search
    BODY ?sourceid=navclient&querytime=-ZMXjB&q=java+development

    Once the server receives this request it can break the BODY down into key=value pairs and exposing them to your code as key/value pair constructs. The confusing thing about all of this is that html makes it very easy to construct these query strings but doesn't really give you access to the raw HTTP requests to insert your xml into. So by using a browser to send your SOAP packets you would just include the SOAP as a key/value pair, very ugly but quick and easy, doing something like this:

    <form action="HTTP://mywebservice/soaphandler" method="post">
    <!-- use post because you can send more data that way -->
    <input type=hidden name="SOAP-REQ" value="$(SOAP-STUFF)">
    </form>

    Now that is really dirty and should be recommended against, I would use a servlet that would parse regular key-value pairs sent from the browser into SOAP requests and forward it to the web service.

    This isn't the way you want to do it, it just seemed like you wanted an example of send SOAP packets just using plain old HTML and a web browser.
  8. Thank you Michael. This is in fact what I was getting at ;^)

    However, what are developers doing out in the field? I too DO NOT want to create SOAP messages in my html forms. I too would convert name/value pairs into some SOAP mapping on the server side.

    So are developers creating SOAP "adapters"? They must be creating mappings, and they must have to manage these mappings. Can anyone discuss some of the architectural decisions they have made, and the failures or successes of these decisions regarding SOAP and Webservices?

    Thank you again

    Jonathan Asbell