Hi Kieran,

I've been made aware that someone sent a completed CLA to the email
address and for some reason it never arrived, so I wanted to make sure
this hasn't also happened to you.  If you haven't sent a completed
CLA, that's fine, but if you have, please let me know, because it
hasn't been received.

Let me know if you have any questions arising from the soap header
work.  As you know, my preference would be for the route which
requires soap extension changes (to avoid polluting the interface).
If this is the approach you are taking, we should start talking to
Dmitry (soap extension maintainer) for how these might look to make
sure they would be acceptable to him to commit to the soap extension
(to avoid having to re-integrate them each release).

Regards,

Graham

On 22 Mar, 18:03, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Hi Kieran,
>
> I like the name @header for a generic header annotation.  It may be
> that other protocols can support the same header data, in which case
> tying it to a specific bindings (e.g. @soapheader) would be too
> limiting.
>
> Have you had any thoughts on the public property vs header method?  It
> looks like the former would require a soap extension change, but would
> be much cleaner.
>
> Regards,
>
> Graham.
>
> On 20 Mar, 20:52, "Kieran James" <[EMAIL PROTECTED]>
> wrote:> Rajini,
>
> > Yes. I've been working on the WSDL generation..
>
> > though I'm not working off the CVS (that needs to change)..I'm working off
> > 1.1.2..
>
> > what are your thoughts on the naming for the annotation?
>
> > Regards,
>
> > Kieran
>
> > On 3/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> > wrote:
>
> > > 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