I have used custom soap processors in most of my projects. Apart from the well known advantages they have over the default soap processors, they also gave me the ability to create a “front-end” component to several services. With a well written custom soap processor, one could also eliminate hard-wiring service invocations (by plucking the QName from SOAP input and locating the service to be invoked).
I read with consternation yesterday that custom soap processors have been deprecated in webM 7.1. From what I have read in the documentation, it looks like I would have to create a default soap processor “target” for each service I intend to expose as a web service. Each such target would have the logic for extracting the soap request payload, service invocation and composing the soap response.
It sounds quite counter-intuitive to me that we need to create a default soap processor target for each service that I need to expose. This would also lead to copying/duplicating all the code that handles soap data. One could argue that soap data handling can be written in a separate utility service to be invoked from the default soap processor targets, but that doesnt take away the fact that there would be lot of services which perform very little function apart from just acting as soap receivers.
Am I missing something very important in webM 7.1 that makes my fears/concerns unfounded?
Custom soap processors are still supported but WM provided what they believe is a better mechanism in IS 7.1.1
One big step forward is that a single web services descriptor node can be used to expose multiple Flow or java services. That provider node can serve up a WS-I compliant WSDL that describes an interface containing one operation for each Flow / Java service you expose.
The web services descriptor nodes receive the soap message, perform any WS-Security processing, deserialize the request payload into IS documents and invoke the appropriate service. This is similar to how the default soap/rpc processor worked before, but supports document/literal as well. It’s also how most of my custom soap processor designs worked, but configurable in Developer instead of XML meta-data files.
One big step backward, IMHO, is the requirement to custom code a JAX-RPC Handler to process any custom header elements. In my experience, most Integration teams don’t have the skill level to do this easily. If they did, they would probably have opted for a java-based soap implementation over IS in the first place.
I was mid way conceptualizing/constructing a generic front end for all web services in our company here (this was meant to work as a custom soap processor) that I saw this piece of information. We were planning to migrate to 7.1 soon, so this was a big dampener
The web service descriptor seems an interesting and useful thing. I am going to research a little into it in the days to come.
You can create quite easily a WebServiceDescriptor from existing flow and java services. Just create new WSD(WebServiceDescriptor) and choose Provider/From Existing IS Services. After you create WSD, you can drag and drop on WSD panel as many IS services as you want! There is an icon, if you click on it you should be able to see the entire WSDL generate using IS services you choose to be part of the web service. Also, you can add new custom SOAP header handlers or other binders.
Has anybody tried to create the custom SOAP header handlers in WM 7.1.2? I am trying to create one to set few fields in the inbound soap message body. So far I created only a skeleton header class implementing
javax.xml.rpc.handler.Handler. I just implemented the required methods, doing really nothing inside, just a system.out.println statement. I am able to register this Handler and add to the WS Descriptor service too. But when I send SOAP message to the server it is throwing execption SOAPException: [ISS.0088.9112] An Exception was thrown in the server:null.
Any idea why that may be?
Could you please help me step wise as how to create to set some fields in the inbound soap message body and how to implement header class implementing
javax.xml.rpc.handler.Handler and also how to register this Handler and add to the WS Descriptor service in 7.1.2.