Announcement Announcement Module
Collapse
No announcement yet.
Implements endpoint processing from native library Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Implements endpoint processing from native library

    Hello,

    I work on a project that use WebServices. As the project already use Spring in several place, I want to use Spring-WS for that part.

    For now, all the SOAP messages processing is done by a native library which take in input the SOAP request and give the whole SOAP response message as output (of, course, there is a java binding jar that provides Java access to the lib).

    In having in mind evolution of services, I whould use Spring-WS for message routing and exception handling, and just implement a specific endpoint to process old SOAP messages with the native library.

    My question is quite general : I'm looking for some advice on how to handle that pb, what part of the spring-ws interface I have to implement, etc.

    In fact, I think that I can see the native lib as kind of (un)marshaller, but that is just a guess...

    Any help would be much appreciate

  • #2
    Interesting!

    I think one idea would be to implement a MessageEndpoint, since that allows access to the entire WebServiceMessage (messageContext.getRequest()). You can write that message to a ByteArrayOutputStream, and pass that byte array to your native library.

    Or, if you only want the envelope, but not attachments, you can cast the WebServiceMessage to a SoapMessage, and read from the Source of the envelope: ((SoapMessage)webServiceMessage).getEnvelope().get Source().

    For the response it's a bit trickier: you have to get the payload (contents of the body) of the response message that you got out of the library, and write that to the payload result (context.getResponse().getPayloadResult()).

    Alternatively, you can implement you own WebServiceMessageFactory, whic creates the message in the native format already, and you just carry a C pointer around. It all depends on the facilities on the library...

    Comment


    • #3
      Thanks you for the response.

      I think I will go on the first proposition, it seems to be quite accordable with the facility of the library. When it's used in Java without Spring-WS, the message processing is something like that, given soapInputMsg is the String of the SOAP message, with is enveloppe & co :

      Code:
      /* choose the good processing task from the rquestType */
      int requestType = MyLib.getRequestTypeFromSoapMsg(soapInputMsg);
      if(requestType == MyLib.Type1 ) {
        MyLib.processQueryMsg(soapInputMsg);
        /* say we want to process a resource given his ID */
        Int resourceId = MyLib.getResourceId();
        /* retrieve relevant Data, etc. The result is an XML String named ressourceData */
        MyLib.setResourceData(ressourceData);
        MyLib.buildResponseMsg(); //this method construct the SOAP response message
        /* I can obtain the message body in an easy way */
        String soapResponse = MyLib.getMsgBody();
        /* send the SOAP message, etc */
      } else ...
      Given that, it should be quite easy to construct the PayloadResult, souldn't be ?

      Thanks again for your answer, I will try that.

      Comment


      • #4
        It works

        Good news : I succeed in sending SOAP messages processed by my native library thanks to Spring WS, it works quite well

        As you advised me, I implemented a MessageEndpoint, get the SOAP message with messageContext.getRequest().writeTo(outputstream), process it with the lib, and send the result with messageContext.readResponse(soapResponseAsStream) (provided in spring-ws 1.0-m3, very good timing

        Thanks you for your help,
        Francois

        Comment


        • #5
          Great!

          I didn't even think of reading the reply like that, good thinking! It just shows that:
          1. I don't know my own API that well (which is a bad thing )
          2. If your API is flexible enough, people will do things you never thought of yourself (which is a good thing )

          Comment

          Working...
          X