Hi Kieran

I've had a think and consulted with a few people.  I'd like to
describe two options.  The first is the easiest to implement and
doesn't pollute the interface, and the second is how we should handle
this kind of thing longer term, but requires quite a bit more work.

Approach 1.  Header class property

I was wondering if we could do something like the following:

 * @service
 * @binding.ws
 * @types http://example.org/ ./header.xsd
class MyService {

    * @header
    * @var http://example.org/ HeaderType
   public $myheader;


The @header would signify that the $myheader property is expected to
come from a header (in this case SoapHeader).  Because it's a class
variable, it won't show up as a WSDL operation, but we could reflect
on it to generate the right information into the WSDL.  The @var
annotation could be used to identify the namespace and type name of
the header.  The actual structure would be defined by the schema which
is contained in the header.xsd.

During initialization of the MyService component we would inject the
SDO instance populated from the soap header.  The MyService component
is then free to use this as appropriate.

There are two open questions for feasibility:

1.  How do we register generically to receive a soap header call from
the SoapServer.  The current implementation as outlined by Rob (thanks
Rob!) appears to rely on us having a PHP function defined which has a
name matching that of the outer header element.
2.  If we can register something, does it use the same type handling
code as the body (i.e. will it give us back an SDO).

I'm optimistic the answer to 2 is "yes", although this would need to
be tested, but I'm pessimistic that there's currently any way to
register a generic function or a class to handle the headers.  This
doesn't appear to fit with the approach that Rob described.  If we go
this route we could prototype and offer a patch to enable it.

Approach 2.  Extensible annotations (a longer term thought)

The problem with the approach above is it still puts what would
normally be infrastructure code into the component.  SCA (the
specifications, not the PHP version) defines a Policy and Intent
mechanism for describing things like security requirements.  We should
make it possible for people to add new annotations (e.g. something
like @authentication) and then write code that implements what that
means for each protocol (e.g. soap/http).

We have started making bindings pluggable using a convention to find
then under the Bindings directory.  We could extend this approach to
look for specific annotations implementation (e.g. Binding/ws/
authentication to find the implementation code for the @authentication

I'd be interested to know whether either of these approaches would
work for what you're trying to achieve



On 6 Mar, 21:51, "Kieran James" <[EMAIL PROTECTED]> wrote:
> Rob,
> I was talking about the PHP SOAP documentation. The SCA documentation seems
> thorough.
> Kieran :)
> On 3/6/07, Rob <[EMAIL PROTECTED]> wrote:
> > On 4 Mar, 16:36, "Kieran James" <[EMAIL PROTECTED]> wrote:
> > > Rob,
> > > Thanks for your input!
> > > I've only had brief exposure to PHP's SOAP (I'm from the Java camp) and
> > I
> > > didn't find the documentation very clear (and for that matter, the book
> > I
> > > bought on "Pro PHP XML and Web Services" doesn't cover Headers except
> > from
> > > the consumers point of view). I'm amazed at the simplicity of it.
> > Sorry about that. I tried to write about as much of the undocumented
> > features, but unfortunately looks like I missed some of it - though it
> > did get me intimate with the ext/soap source code :)
> > Rob

You received this message because you are subscribed to the Google Groups 
"phpsoa" group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to