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