Announcement Announcement Module
No announcement yet.
Converting Sun JWSDP RPC web service to be a SI web service Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Converting Sun JWSDP RPC web service to be a SI web service


    I have a web service built using the Sun JWSDP as a RPC based web service, called by Java and .Net clients. The JWSDP procedure reads the WSDL, creates data beans and builds the web service servlet. I believe JWSDP uses JAXB (1) behind the scenes to make the data beans. This generated sevlet then calls our EJB, and the rest of the web service is Spring POJO based.

    My thinking is the JWSDP stuff could be eliminated by switching to SI and using a <ws:inbound-gateway> with marshaling using the Spring OXM JAXB2 support.

    Since the clients slurp up the WSDL to gen code, and this is RPC based, I was wondering what your thoughts are of switching to SI.

  • #2
    Well, it depends on how much you are willing to refactor. Yes, you are absolutely right. You can simply configure ws:inbond-gateway similar to this sample with marshaller or just use a transformer downstream (more flexible option) and from that point on its a simple Message going straight to your POJO, thus eliminating EJB and other baggage. We can definitely help, but as I said the real question is how much are you allowed to refactor ?


    • #3

      I can refactor any objects past our client facing F5, meaning anything that does not affect the API of the client. In this case, the client API is the WSDL file and the response (which is a byte[] of a PDF file or XML).

      I assume the WSDL, which was used by us for JWSDP and by the client would now not be used by us anymore. We would instead use a XSD for the JAXB2 marshalling.


      • #4
        That's true. So basically what you are saying is that you can refactor anything on the server side. Right? If so I would suggest to start with the sample I included in the previous post and then follow up with more direct questions as it evolves.


        • #5

          Yes exactly, the server side is refactorable. I have already run thru the sample. My next step is a question is about the marshalling. I do not have much experience with Spring OXM, but I am now thinking I need to have a real XSD set up to get to the same point as the JWSDP implementation, which created beans from the request XML. Now you mentioned using a transformer down stream instead of the marshaling. This is sounding better to me, I would like to know your thinking.


          • #6
            IMO using transformer is better because:
            Once you are in the transformer you are under a full control of SI which will greatly simplify error handling (as you know errors will happen ).
            The big difference with gateway configured marshallers is that the marshalling happens as part of the initial Message creation which means you are not yet under full control of SI, just trying to get there. I know it probably sounds complicated, but you have to trust me for now. I am sure we'll get back to this topic later.
            With a simple Transformer you will receive a Message with javax.xml.transform.Source as a payload and then you can apply any XML parsing technique (e.g. XPATH etc.) to get the data from it to construct a POJO payload and than you are in the POJO territory.
            Transformers could be independently monitored
            As any other endpoint the communication protocol between inbound gateway and transformer (polling vs event driven) could be independently managed by managing the type of channel the two are connected (subscribable vs pollable chanel)

            These are just a few benefits, so lets start from here.


            • #7

              I am liking this idea of the transformers. Lets say this web service has five XML messages coming into it, with some xml tag identifying them.

              This is the design I am thinking of:
              ws:inbond-gateway -> router (content) -> five channels -> five transformers (XML to beans) -> service adapters -> some_backend_for_data.

              Would the service adapters usually be one per the output of the transformers, or have less objects with more methods in each service adapters? I am thinking having five SA would be cleaner for unit tests and future changes.


              • #8
                Now you are thinking. That is exactly right. ANd check this out. Since you already mentioned the router and I mentioned that the payload will be Source, you can now apply XPath router
                And yes 5 SA's woud be the right and recommended approach. But keep going, things might change as it evolves.