Announcement Announcement Module
Collapse
No announcement yet.
Support for HTTP URL requests and raw XML Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Support for HTTP URL requests and raw XML

    Hi,

    We've been using Spring in our company with great success and are about to start implementing a couple of Web Services. Luckily, my collegue came across Spring-WS. However, I was wondering if we can actually use it because of two of our requirements:

    1) Clients can send the request either as XML or as HTTP GET request parameters.

    2) We only want to use raw XML and schema files as opposed to SOAP and WSDL.

    Does Spring-WS support these use cases out of the box or is there a way to extend it in order to make it work with our requirements?

    TIA

    Thomas

  • #2
    Originally posted by toellrich
    We've been using Spring in our company with great success and are about to start implementing a couple of Web Services. Luckily, my collegue came across Spring-WS. However, I was wondering if we can actually use it because of two of our requirements:

    1) Clients can send the request either as XML or as HTTP GET request parameters.

    2) We only want to use raw XML and schema files as opposed to SOAP and WSDL.

    Does Spring-WS support these use cases out of the box or is there a way to extend it in order to make it work with our requirements?
    Basically, I think you want REST support, right? The short answer is that it should be possible, but currently not the focus of development.

    Let me elaborate a bit on that: the main concept of Spring-WS in the WebServiceMessage. This interface basically exposes an XML payload. For the SOAP-specific subinterface SoapMessage, the payload is the contents of the body. For a REST-like Plain Old Xml (POX) message, this will be the contents of the entire message (with no wrapping SOAP envelope). The good news is that most endpoint classes in Spring-WS only use the payload, so that they can be used within REST environment. In general, all soap-specific stuff is in org.springframework.ws.soap and subpackages, but all other packages should be usable in REST environments. The main difference being that RESTS depends on HTTP directly, while SOAP is moving away from HTTP more and more.

    With regard to WSDLs: if you don't need it, don't write it!

    So, how I would do this (if I only had the time ), is to create a implementation of WebServiceMessage called RestMessage or something similar. You can add the HTTP request to this class, so that you can use them in the endpoints. You should also create a RestMessageContext and a RestMessageContextFactory that are responsible for creating the RestMessages (look at SaajSoapMessageFactory for an example). Additionally, you will need to create a EndpointMapping that uses the HTTP Request in the RestMessasge to route the message to an endpoint (I would call it a UrlEndpointMapping, you can look at the various other endpoint mapping implementations for examples). And that should basically be it: you should be able to use marshalling, and all other various ways to handle XML without being dependant on SOAP.

    Like I said before: my current focus is SOAP, but I would be really happy if someone would implement this. During development so far, I made an effort not to depend on SOAP where it didn't make sense, so that REST would be possible.

    Let me know if you need any further help.

    Cheers,

    Arjen

    Comment


    • #3
      Currently, I am working on a application that receives XML messages over HTTP Request and responds again XML messages over HTTP responses.

      I am using spring-oxm with JAXB and a very simple servlet that extracts the incoming message from http request and writes the outcoming messahe to http response.

      HTML Code:
      public interface MyBusinessProcessor {
         
            MyResult process(MyObject x);
      
      }
      
      public class MyXmlProcessor {
         
         private Unmarshaller unmarshaller;
         private Marshaller marshaller;
         private MyBusinessProcessor businessProcessor;
      
         public void process(Source incomingMessage, Result outcomingMessage) { 
            MyObject x = unmarshaller.umarshall(incomingMessage);
            MyResult y = businessProcessor.process(x);
            marshaller.marshal(y, outcomingMessage);
      }
      
      }
      
      public class MyProcessServlet ... {
      
         private MyXmlProcess myXmlProcessor;
      
         public void doGet(...) {
             Source incoming = new StreamSource(request.getInputStream());
             Result outcoming = new StreamResult(response.getOutputStream());
             myXmlProcessor.process(incoming, outcoming);
             response.flushBuffer();
         }
      }

      Comment


      • #4
        Arjen,

        Thanks a lot for the detailed instructions. I was wondering, however, since WebServiceMessage is XML-centric, how would you handle HTTP GET parameter requests? Would you convert these requests into XML first so that they can tie into the remaining API? I'm just a little bit concerned about the performance overhead since the request parameters could be converted directly into Java schema objects.

        Also, I was wondering if we would still be able to use the security features of Spring-WS even if we decided not to use SOAP?

        Many thanks,

        Thomas
        Last edited by toellrich; Jul 6th, 2006, 10:30 AM.

        Comment


        • #5
          Originally posted by toellrich
          Thanks a lot for the detailed instructions. I was wondering, however, since WebServiceMessage is XML-centric, how would you handle HTTP GET parameter requests? Would you convert these requests into XML first so that they can tie into the remaining API? I'm just a little bit concerned about the performance overhead since the request parameters could be converted directly into Java schema objects.
          Yes, the WebServiceMessage is XML-centric, but the RestMessage subinterface (or class) can add HTTP stuff, just like SoapMessage adds SOAP-specific stuff. You can pickup the HTTP parameters from it.

          Originally posted by toellrich
          Also, I was wondering if we would still be able to use the security features of Spring-WS even if we decided not to use SOAP?
          You cannot use WS-Security, since that is a SOAP-based standard. You can however use plain vanilla Acegi, since you are basing yourself on HTTP completely.

          If you are really interested in this functionality, I can create an issue for it, and implement it for a future release.

          Cheers,

          Comment

          Working...
          X