We now have a provider and router that can pass the SOAP header to our service methods, so let's go ahead and implement a service that uses the SOAP header. The urn:ProxyQuoteService from Chapter 9 is a good place to start. Its implementation hardcoded the physical address of the back-end service as http://mindstrm.com:8004/glue/urn:CorpDataServices; we'll ask the client application to provide that information as part of the SOAP header. Our proxy service defaults to a bogus address of http://mindstrm.com:8899/glue/urn:CorpDataServices if no routing data appears in the header. You might use a similar technique if the service accesses a default back-end service but can also be directed to a client-specified service via the SOAP header.
Let's design our SOAP header so that it contains a single child element named targetAddress. This element contains the back-end service address that the proxy should use. The elements within the header may use the SOAP-ENV:mustUnderstand attribute with a value of "1" to indicate that the recipient of the envelope must understand the header element and properly use the data provided. The SOAP header sent by a client that demands the understanding of the targetAddress should look like this:
<SOAP-ENV:Header> <targetAddress SOAP-ENV:mustUnderstand="1"> http://mindstrm.com:8004/glue/urn:CorpDataServices </targetAddress> </SOAP-ENV:Header>
So let's design our service to understand the targetAddress ...