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 annotation). I'd be interested to know whether either of these approaches would work for what you're trying to achieve Regards, Graham. 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 http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
