RE: [asap] Guidance on SOAP Headers?

[Keith Swenson <KSwenson@fsw.fujitsu.com>]

Title: RE: [asap] Guidance on SOAP Headers?

The header should be used:

a) for things that are needed between the originator and destination.  If there is any routing involved, multiple hops, etc.  These things in between should be able to get all of their information from the header.  Of course, all of these things have to do with the basic ability to get a message from point A to point B.

b) things that are common across all web services.  WS-CAF employs a 'context' which is delivered to all web services regardless of the service they are providing.  Thus one service may be retrieving a customer credit record, while another is reserving a potential phone number.  If these two services are to work in the context of a single, two phase commit, then they must be informed of the context.  The Context itself is not the 'subject' of the interaction, but a standard attachment to it.  Headers are justified in this case becase we do not want to impact the subject of the message which may be fixed.

What can we say about when the header should NOT be used.  If the information being carried is specific to the operation at hand.  If the purpose of the command is to do X, then the body should carry all the information necessary to do X.

So.  The current specificaitions uses headers for four main things:
* the to address
* the from address
* the message id
* a 'response needed' flag

"WS-Reliability" specifies everything for a message id, and we should use that spec fo that.  I suspect that the to address and the from address are duplicates of some other SOAP standard.  I don't know about the response needed flag.

What other information could be put in the header?  "observer key" has been suggested on the phone conference call.  But the observer key is needed only for one operation: the create instance operation.  No other operation needs it passed as a head item.  It is, of course, address that many messages are sent to, so the address may appear in the 'to' or the 'from' address, but I see no reason to has an 'observer' field in the header.

I think you will find that the information being sent in the body of the proposed ASAP standard is always information needed for that particular operation, no more no less.

For example, consider the Subsrcribe operation.  In order to subscribe, you need to send an address for events  to be send to.  The context or restlt data is NOT part of this message.  The information in the body is what the operation needs, and I don't see how any of this can be moved to the header.

Another example: 'GetProperties'.  The request contains only a single tag "GetProperties" and the result contains both the standard properties (name, description, priority) as well as the customer properites (context data and its sub tags).  I don't see how any of this can be moved to the header.

Therefor, we are waiting for a write up of exactly what will be moved to the header so we can evaluate whether it is better or not.

-Keith

-----Original Message-----
From: Jeffrey Ricker [mailto:ricker@izartech.com]
Sent: Wednesday, November 19, 2003 4:19 AM
To: ASAP
Subject: Re: [asap] Guidance on SOAP Headers?

Thank you, Anne.

Can you site chapter and verse for me? What are you quoting here? Where
did it come from?

On Tue, 2003-11-18 at 18:46, Anne Thomas Manes wrote:
> The SOAP body should contain application payload information. Any
> information that isn't directed at the Web service agent should be carried
> in the header.
>
> Anne
>
> At 02:07 PM 11/18/2003, you wrote:
> >Has anyone come across guidance from either the SOAP or XML Protocol
> >committees at W3C on what should be in the SOAP Header versus the SOAP
> >Body?
> >
> >
> >To unsubscribe from this mailing list (and be removed from the roster of
> >the OASIS TC), go to
> >http://www.oasis-open.org/apps/org/workgroup/asap/members/leave_workgroup.php.
>
>

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/asap/members/leave_workgroup.php.