Can someone please throw some light on what is the purpose of having a custom soap processor? We are heavily using web services at our institute and i’m trying to find what are the benefits of having a custom made soap processor? Is it be worth moving towards that direction in long run? What are the advantages?

Thanks for all your replies,
Leon

Reasons to create a custom document / literal SOAP processor:

• In Integration Server versions 4.6 through 6.5, exposing Flow or Java services as document / literal web service operations requires creation of one “wrapper” service for each service to be exposed. Creating a custom document / literal soap processor to perform this “wrapper” functionality eliminates this redundant code, making it nearly as easy to expose doc/lit style operations as rpc/encoded ones.
• A custom doc/lit soap processor provides an effective layer in which to pre-process document / literal style soap requests. Typical pre-processing functionality may include: XML validation, service name lookup or derivation, request / response logging and soap header processing.
• A custom doc/lit soap processor provides an ideal point to process WS-Security tokens to perform authentication and / or authorization prior to invoking the requested service.
• A custom doc/lit soap processor is an effective point to create consistent custom soap fault handling. This can be used to provide custom, faultDetail contents or to hide implementation details that would be exposed to would-be hackers.
• A custom soap processor is a good place to interact with custom or third-party registry / repository applications to enforce runtime policies if an intermediary to do those things is not already in place. For those of us who have been waiting for 3-4 years for WM to provide a working intermediary (Gaia, Fabric, ServiceNet, Infravio / CentraSite) this means we can get work done now without waiting on slow (or chaotic) product delivery cycles.
• By registering custom soap processors with unique “directives” you can add new endpoints to which soap requests can be sent to Integration Server. If you desire, you can create multiple soap processor each with its own behavior. For example, one processor might always require a WS-Security token to be present, while another might not.
• As you would expect, placing all of the soap protocol-specific functionality in a single component promotes consistency. By assigning the design and construction of such as task to an expert-level developer, you also get efficient, performant code rather than having every developer “roll their own”.
• Finally, a custom soap processor is only a Flow service that offloads soap request and response handling from the each Flow or Java service to be exposed. If you can create a doc/lit “wrapper” service, you can probably create a custom soap processor that will do the same for any service you want to expose as a doc/lit web service operation.

Mark