The term "actor" is a little misleading. In SOAP 1.2, this header attribute is referred to as "role" instead, which I think conveys its meaning a little better. The purpose of the SOAP actor attribute (see http://www.w3.org/TR/SOAP/#_Toc478383499), which may be included in a SOAP Header block, is to specify the role of the SOAP node that is supposed to process the Header block, but it does not specify routing information. To clarify, a SOAP message may contain a number of Header blocks, such as a reliability header, a security header, and a chargeback header. Such a message might be routed through three different intermediaries en route to its final destination: a queuing service, a security service, and a metering service, or it might be routed through a single intermediary that performs all three functions, or the ultimate receiver node might take responsibility for processing these headers using built-in header processors. The sending node doesn't necessarily need to know how the message will be routed, or which nodes will actually process each header. The sending node just needs to specify the "role" associated with each Header block and send the message to the URL if the SOAP node specified in the soap:location attribute in the WSDL file. It's up to that SOAP node to either process the message or forward it to the next node in the chain. So my point is that you don't use SOAP actor to specify the URL of the intermediary node. You use it to specify the name (URI) of the role that a SOAP node must play to process the header block. If you don't specify the SOAP actor attribute, then the header block is targeted at the ultimate receiver. A SOAP node may be associated with any number of roles. All SOAP nodes play the role of " http://schemas.xmlsoap.org/soap/actor/next" -- which simply means "the next node in the chain". A SOAP node must process all header blocks that specify its associated roles, and it must ignore all header blocks that specify roles it does not play. If the SOAP node doesn't understand one of its targeted header blocks, and the header block specifies mustUnderstand="1", then the SOAP node must return a MustUnderstand fault. If the SOAP node doesn't understand one of its targeted header blocks, and the header block doesn't specify mustUnderstand="1", then the SOAP node must remove the header block without processing it.
So back to your basic question, there are two ways to implement a header processor: either as a SOAP intermediary or as a SOAP interceptor. A SOAP intermediary must be a SOAP node, and you must route the message via that node. You can configure a SOAP intermediary as a proxy node or as a Web server filter (e.g., a servlet filter). A SOAP interceptor, which in a JAX-RPC environment would be implemented as a JAX-RPC Handler in your handler chain, is called by the ultimate receiver while processing the SOAP message.
I suspect that you'd like to implement your intermediary as a servlet filter. You must intercept the call between the point that the servlet engine receives the HTTP call and before it routes it to the SOAP message handler. Once your servlet filter has finished processing the header, the servlet engine will route the call to the SOAP message handler.
Related Q&A from Anne Thomas Manes
Anne Thomas Manes explains the differences between open source clients and open source implementations.continue reading
Anne Thomas Manes discusses the best way to go about creating an enterprise data dictionary and why the systems works well.continue reading
Anne Thomas Manes explains the difference between 'hard' real time and 'live' real time systems.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.