Anne,
We know from your postings and examples in the Axis (I use 1.3) release that we can specify the SOAP <header> in the WSDL. But all examples I seen are not "wrapped" document/literal, thus not WS-I compliant. If I write the WSDL strictly follows the "wrapped" document/literal style and include the <header> in the input binding, Axis wsdl2java just ignores the <header> in the generated classes.
Similar questions are posted several times, including one by myself. Since this is very important, I really want to get an answer. Do you know if this is just not supported by Axis or is it a bug? Should we post this question to soap_dev?
Thanks.
Shaoguang
Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
Susae,
Most web services posted on xmethods.com are for demo purposes only. They don't require authentication, monitoring, auditing, routing, transformations, or any additional infrastructure functionality. As a best practice, business-oriented services should require authentication, and they should be monitored and audited. These functions don't require intermediation (you can use transport-level authentication [HTTP Auth or SSL mutual auth] for 1-to-1 connections), but many organizations choose to use an intermediary to implement this functionality.
Routing, transformations, and acceleration typically require an intermediary. When using intermediaries, you typically also need to shift to application-level security (WS-Security).
The "ultimate receiver" is the last SOAP node to receive the SOAP message. It comprises a SOAP engine and an application agent. The SOAP engine processes the SOAP message -- both Header and Body. Typically it uses handlers to processs the Header element, and serializers to convert the Body into language objects. The application agent is the application code that gets dispatched after the SOAP engine has processed the incoming message. If an response is required, the agent returns a language object return value to the SOAP engine, which then transforms it into a SOAP Response message, and then uses handlers to construct any necessary Header blocks.
A handler and an intermediary are different things. A handler runs within the SOAP node. An intermediary is a separate SOAP node.
Anne
On 3/7/06, susae lee <[EMAIL PROTECTED]> wrote:you mention routing - if you sent soap to a host for routing then it's not 1-to-1 and must be intermediated connection, correct ?you mean most web services are very simple sample for demo only and commerical implementations are much more complex?and you mention "application agent" are u mening Ultimate SOAP receiver?you mention "intermediary" is meaning same as "handler with the hosting SOAP engine." correct?People typically use a SOAP Header to perform system-level functionality, such as authentication, session management, and routing. These functional requirements apply to both 1-to-1 and intermediated connections.
Most web services on xmethods.com do not require these system-level functions.
Typically header information is not passed to the application agent. Instead, the header is processed either by an intermediary or by a handler with the hosting SOAP engine.
Anne
On 3/5/06, susae lee <[EMAIL PROTECTED] > wrote:i just read through Axis user doc, but all sample app it mention doesn't show how to use the <HEADER> tag inside soap request / response.1 -- is <HEADER> tag not much a use when doing 1 - 1 host to host request /response?2 -- <HEADER> is only useful when soap massage need to pass multiple endpoints / hosts ?3 -- Why most of the web services at www.xmethods.net don't use <HEADER> tag on request / response xml?4 -- Is that in most cases, BODY tag in soap is enough? no HEADER needed?5 -- Hosts in between web service client + provider process <HEADER> elements but not the content of BODY element? and the Ultimate SOAP receiver will process the BODY elements?
Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.
Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.
Yahoo! Mail
Use Photomail to share photos without annoying attachments.
