I have been looking at the support required to handle headers using
Approach 1
that Graham described.

At the moment, SDO_TypeHandler gets called to decode the header if an
element
is defined in the WSDL with the same name as the type of the header.
Using
Graham's example, SDO_TypeHandler.fromXml is called if an element
'HeaderType'
is defined in the WSDL. In addition, if a method of name 'HeaderType'
is present in the
component, the method gets called. Since the SCA Soap Proxy does not
set
'mustUnderstand' to true, no errors are raised if the element
'HeaderType' is not defined
in the WSDL. SDO_TypeHandler.fromXml and the method corresponding to
the header
are called even if 'mustUnderstand' is not set.

So it looks like we can use SDO_TypeHandler.fromXml to handle headers
and call
appropriate methods defined in annotations in the component if the
header
type is a complex type. The WSDL generator needs to be modified to add
the types
and message corresponding to the header, as well as the header for the
operation elements.

Kieran, is this along the lines of what you are planning to do?

Rajini



On 6 Mar, 22:02, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> 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
>  * @typeshttp://example.org/./header.xsd
>  *
>  */
> class MyService {
>
>    /**
>     * @header
>     * @varhttp://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- Hide quoted text -
>
> - Show quoted text -


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to