[phpsoa] Re: SOAP Headers
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
[phpsoa] Re: SOAP Headers
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
[phpsoa] Re: SOAP Headers
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 PROTE
[phpsoa] Re: SOAP Headers
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
[phpsoa] Re: SOAP Headers
Hi Kieran,
I've just updated the CLA to reflect the project rename. It's under
the AVOCET branch pecl/sdo/CLA.txt. To make life a little easier,
I'll send you a copy directly because it looks like the google group
mucks up the formatting a bit.
Regards,
Graham.
On 7 Mar, 08:23, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Hi Kieran,
>
> I'm assured the approach just requires you to complete the form
> electronically and then send it to the email address (no physical
> signature necessary). Let me find the answer to the name change
> before you do this, to avoid the possibility of having to do it twice.
>
> BTW: did you see the other post regarding additional options for
> specifying / implementing soap header support (I did two posts in
> quick succession and wanted to make sure the first wasn't lost)?
>
> Regards,
>
> Graham.
>
> On 7 Mar, 06:50, "Kieran James" <[EMAIL PROTECTED]> wrote:
>
> > Graham,
>
> > No I wasn't aware of that license agreement.
>
> > I'm happy with that agreement and am willing to sign the contract. The
> > license agreement states that I should sign the document, are they
> > suggesting pen-to-paper signature or otherwise? In either case, I'm happy
> > to.
>
> > Regards,
>
> > Kieran
>
> > On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > > Hi Kieran,
>
> > > On the subject of Contributors License Agreement, I just wanted to
> > > make sure we're talking about the same thing (for my peace of
> > > mind :-) ). SCA_SDO has two licenses, one which covers people using
> > > the project (this is just the standard Apache 2 license and is linked
> > > to in the code copyright statements), and one which covers people
> > > contributing code to the project. The second license is there to
> > > ensure that anyone contributing code and intellectual property has the
> > > right to do so. This is in place to protect contributors and users of
> > > the project (see Apache, Zend Framework and eZ Component for other
> > > projects which use CLAs).
>
> > > The Contributors License Agreement is as follows and can be found in
> > > the downloadable package. The process is to send a completed copy to
> > > the email address mentioned in the agreement. If you choose to
> > > complete and send the agreement, please could you copy me on the note
> > > so I know where we are :-) . Let me know if you have any questions
> > > about this (BTW: I'm still trying to find out about the project name
> > > change - SDO changed to SCA_SDO).
>
> > > Is this the license you were referring too?
>
> > > SDO for PHP: Individual Contributor License Agreement ("Agreement")
>
> > > Thank you for your interest in the SDO for PHP Project, a project that
> > > IBM has
> > > contributed to and is moving forward with the open source community.
> > > In order to
> > > clarify the intellectual property license granted with Contributions
> > > from any
> > > person or entity, the SDO for PHP project requires all contributors to
> > > submit an
> > > individual Contributor License Agreement ("CLA"), indicating their
> > > agreement to
> > > the license terms below. This Agreement is for your protection as a
> > > Contributor, as well as for the protection of the Project and its
> > > users as a
> > > whole; in particular, it is not intended that this Agreement should
> > > change any
> > > of your rights to use your own Contributions for any other purpose.
>
> > > If you have not already done so, please complete and send the
> > > Agreement to SDO
> > > for PHP project at [EMAIL PROTECTED] Please read this document
> > > carefully
> > > before signing, and keep a copy for your records.
>
> > > Full name:
>
> > > E-Mail:
>
> > > php.net user ID:
>
> > > Mailing Address:
> > >
> > >
> > >
> > > Telephone:
>
> > > Facsimile:
>
> > > Country:
>
> > > You accept and agree to the following terms and conditions for Your
> > > present and
> > > future Contributions submitted to the SDO for PHP project.
> > > 1. Definitions.
> > >"You" (or "Your") means (or refers to) the person signing this
> > > Agreement and
> > >includes, if the signatory is representing an organization or other
> > > legal
> > >entity, that legal entity and any of its subsidiaries or
> > > Affiliates, as
> > >identified below.
> > >"Affiliate" means an entity that directly or indirectly Controls,
> > > is
> > >Controlled by or is under common Control with, a party to this
> > > Agreement;
> > >and, for these purposes, "Control" shall mean the direct or
> > > indirect
> > >beneficial ownership of more than fifty percent (50%) of the voting
> > > stock of,
> > >or decision making authority in the event t
[phpsoa] Re: SOAP Headers
Hi Kieran,
I'm assured the approach just requires you to complete the form
electronically and then send it to the email address (no physical
signature necessary). Let me find the answer to the name change
before you do this, to avoid the possibility of having to do it twice.
BTW: did you see the other post regarding additional options for
specifying / implementing soap header support (I did two posts in
quick succession and wanted to make sure the first wasn't lost)?
Regards,
Graham.
On 7 Mar, 06:50, "Kieran James" <[EMAIL PROTECTED]> wrote:
> Graham,
>
> No I wasn't aware of that license agreement.
>
> I'm happy with that agreement and am willing to sign the contract. The
> license agreement states that I should sign the document, are they
> suggesting pen-to-paper signature or otherwise? In either case, I'm happy
> to.
>
> Regards,
>
> Kieran
>
> On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > Hi Kieran,
>
> > On the subject of Contributors License Agreement, I just wanted to
> > make sure we're talking about the same thing (for my peace of
> > mind :-) ). SCA_SDO has two licenses, one which covers people using
> > the project (this is just the standard Apache 2 license and is linked
> > to in the code copyright statements), and one which covers people
> > contributing code to the project. The second license is there to
> > ensure that anyone contributing code and intellectual property has the
> > right to do so. This is in place to protect contributors and users of
> > the project (see Apache, Zend Framework and eZ Component for other
> > projects which use CLAs).
>
> > The Contributors License Agreement is as follows and can be found in
> > the downloadable package. The process is to send a completed copy to
> > the email address mentioned in the agreement. If you choose to
> > complete and send the agreement, please could you copy me on the note
> > so I know where we are :-) . Let me know if you have any questions
> > about this (BTW: I'm still trying to find out about the project name
> > change - SDO changed to SCA_SDO).
>
> > Is this the license you were referring too?
>
> > SDO for PHP: Individual Contributor License Agreement ("Agreement")
>
> > Thank you for your interest in the SDO for PHP Project, a project that
> > IBM has
> > contributed to and is moving forward with the open source community.
> > In order to
> > clarify the intellectual property license granted with Contributions
> > from any
> > person or entity, the SDO for PHP project requires all contributors to
> > submit an
> > individual Contributor License Agreement ("CLA"), indicating their
> > agreement to
> > the license terms below. This Agreement is for your protection as a
> > Contributor, as well as for the protection of the Project and its
> > users as a
> > whole; in particular, it is not intended that this Agreement should
> > change any
> > of your rights to use your own Contributions for any other purpose.
>
> > If you have not already done so, please complete and send the
> > Agreement to SDO
> > for PHP project at [EMAIL PROTECTED] Please read this document
> > carefully
> > before signing, and keep a copy for your records.
>
> > Full name:
>
> > E-Mail:
>
> > php.net user ID:
>
> > Mailing Address:
> >
> >
> >
> > Telephone:
>
> > Facsimile:
>
> > Country:
>
> > You accept and agree to the following terms and conditions for Your
> > present and
> > future Contributions submitted to the SDO for PHP project.
> > 1. Definitions.
> >"You" (or "Your") means (or refers to) the person signing this
> > Agreement and
> >includes, if the signatory is representing an organization or other
> > legal
> >entity, that legal entity and any of its subsidiaries or
> > Affiliates, as
> >identified below.
> >"Affiliate" means an entity that directly or indirectly Controls,
> > is
> >Controlled by or is under common Control with, a party to this
> > Agreement;
> >and, for these purposes, "Control" shall mean the direct or
> > indirect
> >beneficial ownership of more than fifty percent (50%) of the voting
> > stock of,
> >or decision making authority in the event that there is no voting
> > stock in, a
> >relevant entity.
> >"Contribution" means any original work of authorship, including any
> >modification or addition to an existing work, that is intentionally
> > submitted
> >by You to the SDO for PHP project for inclusion in, or
> > documentation of, any
> >of the products owned or managed by the SDO for PHP project; and,
> > for these
> >purposes, "Submitted" includes any form of electronic, verbal, or
> > written
> >communication sent to the S
[phpsoa] Re: SOAP Headers
Graham,
No I wasn't aware of that license agreement.
I'm happy with that agreement and am willing to sign the contract. The
license agreement states that I should sign the document, are they
suggesting pen-to-paper signature or otherwise? In either case, I'm happy
to.
Regards,
Kieran
On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> Hi Kieran,
>
> On the subject of Contributors License Agreement, I just wanted to
> make sure we're talking about the same thing (for my peace of
> mind :-) ). SCA_SDO has two licenses, one which covers people using
> the project (this is just the standard Apache 2 license and is linked
> to in the code copyright statements), and one which covers people
> contributing code to the project. The second license is there to
> ensure that anyone contributing code and intellectual property has the
> right to do so. This is in place to protect contributors and users of
> the project (see Apache, Zend Framework and eZ Component for other
> projects which use CLAs).
>
> The Contributors License Agreement is as follows and can be found in
> the downloadable package. The process is to send a completed copy to
> the email address mentioned in the agreement. If you choose to
> complete and send the agreement, please could you copy me on the note
> so I know where we are :-) . Let me know if you have any questions
> about this (BTW: I'm still trying to find out about the project name
> change - SDO changed to SCA_SDO).
>
> Is this the license you were referring too?
>
> SDO for PHP: Individual Contributor License Agreement ("Agreement")
>
> Thank you for your interest in the SDO for PHP Project, a project that
> IBM has
> contributed to and is moving forward with the open source community.
> In order to
> clarify the intellectual property license granted with Contributions
> from any
> person or entity, the SDO for PHP project requires all contributors to
> submit an
> individual Contributor License Agreement ("CLA"), indicating their
> agreement to
> the license terms below. This Agreement is for your protection as a
> Contributor, as well as for the protection of the Project and its
> users as a
> whole; in particular, it is not intended that this Agreement should
> change any
> of your rights to use your own Contributions for any other purpose.
>
> If you have not already done so, please complete and send the
> Agreement to SDO
> for PHP project at [EMAIL PROTECTED] Please read this document
> carefully
> before signing, and keep a copy for your records.
>
>
> Full name:
>
> E-Mail:
>
> php.net user ID:
>
>
> Mailing Address:
>
>
>
> Telephone:
>
>
> Facsimile:
>
>
> Country:
>
>
> You accept and agree to the following terms and conditions for Your
> present and
> future Contributions submitted to the SDO for PHP project.
> 1. Definitions.
>"You" (or "Your") means (or refers to) the person signing this
> Agreement and
>includes, if the signatory is representing an organization or other
> legal
>entity, that legal entity and any of its subsidiaries or
> Affiliates, as
>identified below.
>"Affiliate" means an entity that directly or indirectly Controls,
> is
>Controlled by or is under common Control with, a party to this
> Agreement;
>and, for these purposes, "Control" shall mean the direct or
> indirect
>beneficial ownership of more than fifty percent (50%) of the voting
> stock of,
>or decision making authority in the event that there is no voting
> stock in, a
>relevant entity.
>"Contribution" means any original work of authorship, including any
>modification or addition to an existing work, that is intentionally
> submitted
>by You to the SDO for PHP project for inclusion in, or
> documentation of, any
>of the products owned or managed by the SDO for PHP project; and,
> for these
>purposes, "Submitted" includes any form of electronic, verbal, or
> written
>communication sent to the SDO for PHP project or its
> representatives or to
>SDO for PHP project-run electronic mailing lists, source code
> control
>systems, or issue tracking systems. Contributions do not include
> any
>communication that is conspicuously marked or otherwise designated
> in writing
>by You as "Not a Contribution".
>
> 2. Grant of Copyright License.
> Subject to the terms and conditions of this Agreement, You hereby
> grant to the
> SDO for PHP project, and to recipients of software and other materials
> distributed by the SDO for PHP project, a perpetual, world-wide, non-
> exclusive,
> no-charge, royalty-free, irrevocable copyright license to reproduce,
> prepare
> derivative works of, publicly display, publicly
[phpsoa] Re: SOAP Headers
Hi Kieran,
On the subject of Contributors License Agreement, I just wanted to
make sure we're talking about the same thing (for my peace of
mind :-) ). SCA_SDO has two licenses, one which covers people using
the project (this is just the standard Apache 2 license and is linked
to in the code copyright statements), and one which covers people
contributing code to the project. The second license is there to
ensure that anyone contributing code and intellectual property has the
right to do so. This is in place to protect contributors and users of
the project (see Apache, Zend Framework and eZ Component for other
projects which use CLAs).
The Contributors License Agreement is as follows and can be found in
the downloadable package. The process is to send a completed copy to
the email address mentioned in the agreement. If you choose to
complete and send the agreement, please could you copy me on the note
so I know where we are :-) . Let me know if you have any questions
about this (BTW: I'm still trying to find out about the project name
change - SDO changed to SCA_SDO).
Is this the license you were referring too?
SDO for PHP: Individual Contributor License Agreement ("Agreement")
Thank you for your interest in the SDO for PHP Project, a project that
IBM has
contributed to and is moving forward with the open source community.
In order to
clarify the intellectual property license granted with Contributions
from any
person or entity, the SDO for PHP project requires all contributors to
submit an
individual Contributor License Agreement ("CLA"), indicating their
agreement to
the license terms below. This Agreement is for your protection as a
Contributor, as well as for the protection of the Project and its
users as a
whole; in particular, it is not intended that this Agreement should
change any
of your rights to use your own Contributions for any other purpose.
If you have not already done so, please complete and send the
Agreement to SDO
for PHP project at [EMAIL PROTECTED] Please read this document
carefully
before signing, and keep a copy for your records.
Full name:
E-Mail:
php.net user ID:
Mailing Address:
Telephone:
Facsimile:
Country:
You accept and agree to the following terms and conditions for Your
present and
future Contributions submitted to the SDO for PHP project.
1. Definitions.
"You" (or "Your") means (or refers to) the person signing this
Agreement and
includes, if the signatory is representing an organization or other
legal
entity, that legal entity and any of its subsidiaries or
Affiliates, as
identified below.
"Affiliate" means an entity that directly or indirectly Controls,
is
Controlled by or is under common Control with, a party to this
Agreement;
and, for these purposes, "Control" shall mean the direct or
indirect
beneficial ownership of more than fifty percent (50%) of the voting
stock of,
or decision making authority in the event that there is no voting
stock in, a
relevant entity.
"Contribution" means any original work of authorship, including any
modification or addition to an existing work, that is intentionally
submitted
by You to the SDO for PHP project for inclusion in, or
documentation of, any
of the products owned or managed by the SDO for PHP project; and,
for these
purposes, "Submitted" includes any form of electronic, verbal, or
written
communication sent to the SDO for PHP project or its
representatives or to
SDO for PHP project-run electronic mailing lists, source code
control
systems, or issue tracking systems. Contributions do not include
any
communication that is conspicuously marked or otherwise designated
in writing
by You as "Not a Contribution".
2. Grant of Copyright License.
Subject to the terms and conditions of this Agreement, You hereby
grant to the
SDO for PHP project, and to recipients of software and other materials
distributed by the SDO for PHP project, a perpetual, world-wide, non-
exclusive,
no-charge, royalty-free, irrevocable copyright license to reproduce,
prepare
derivative works of, publicly display, publicly perform, sublicense,
and
distribute each of Your Contributions and such derivative works.
3. Grant of Patent License.
Subject to the terms and conditions of this Agreement, You hereby
grant to the
SDO for PHP project, and to recipients of software and other materials
distributed by the SDO for PHP project, a perpetual, world-wide, non-
exclusive,
no-charge, royalty-free, irrevocable (except as stated in this
section) patent
license to make, have made, use, offer to sell, sell, import, and
otherwise
transfer each of Your Contributions, where such license applie
[phpsoa] Re: SOAP Headers
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
-~--~~~~--~~--~--~---
[phpsoa] Re: SOAP Headers
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 -~--~~~~--~~--~--~---
[phpsoa] Re: SOAP Headers
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 -~--~~~~--~~--~--~---
[phpsoa] Re: SOAP Headers
Graham,
I understand your concerns regarding the annotations and eagerly await your
thoughts on the subject.
My management and I have already looked into the licensing agreement and we
are happy with it.
All the best,
Kieran
On 3/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> Hi Kieran,
>
> Sorry for not replying sooner. That's great news that you have
> approval to work on this.
>
> I'm a little concerned about having a soap header method on the
> component because this will appear on any generated service interface
> (e.g. .wsdl, .smd, etc), but should not be expliclity called by
> clients. I guess we could exclude this in some way, but if there's a
> way to separate it out, it might be better. I'll have a think about
> this tomorrow and be sure to respond (even if I don't have any better
> ideas).
>
> FYI: the SCA_SDO project has an associated Contributors License
> Agreement (CLA) (similar to that of Apache and the Zend Framework).
> If you are willing to contribute the header support, it would need to
> be done under this CLA. The CLA text file is in the PECL repository
> and packaged in each release. I've noticed the CLA still refers to
> the old project name (SDO) and will check whether or not this needs to
> be fixed. If you have any questions about the CLA, please let me
> know.
>
> Regards, Graham.
>
> On 5 Mar, 22:09, "Kieran James" <[EMAIL PROTECTED]> wrote:
> > If there are no objections, I'll start work on it.
> >
> > Regards,
> >
> > Kieran
> >
> > On 3/4/07, 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.
> >
> > > Everyone,
> >
> > > My manager has approved me to work on SCA - specifically the
> > > implementation of header support.
> >
> > > I suggest we work on the semantics of how this should work.
> >
> > > I think we should have an annotation above the class that defines
> which
> > > function is going to process the header from the client, and
> annotations
> > > above that function which defines the datatypes and such, for example:
> >
> > > /**
> > > * @service
> > > * @binding.ws
> > > * @header authinfo
> > > */
> > > class service {
> >
> > > /**
> > > * @param username $usernamehttp://accounts/Account
> > > * @return statushttp://accounts/Account
> > > */
> > > function authinfo($username) {
> >
> > > }
> >
> > > }
> >
> > > If you have any thoughts, please let me know as I'd like to start work
> on
> > > this as soon as possible.
> >
> > > Regards,
> >
> > > Kieran
> >
> > > On 3/2/07, Rob <[EMAIL PROTECTED]> wrote:
> >
> > > > On 1 Mar, 21:31, "Kieran James" <[EMAIL PROTECTED]>
> wrote:
> > > > > I've only had a small amount of time to review the PHP SOAP
> extension.
> > > > To
> > > > > summarize from my brief exposure to it, I think that SoapHeader
> > > > consumption
> > > > > on the server side wouldn't be difficult to implement. I am still
> > > > > investigating this, though time is scarce for me.
> >
> > > > > If I've not been clear enough on anything, please let me know.
> >
> > > > I am not sure if I'm missing something or not, but a SoapServer does
> > > > process the headers as long as they are defined in the WSDL.
> > > > It also will fault if header set to mustUnderstand and the function
> > > > not implemented or not defined in WSDL.
> > > > The only times the raw XML needs to be processed to access the
> headers
> > > > is in the case of it not defined.
> >
> > > > > > > $xmlinput = << > > > http://schemas.xmlsoap.org/soap/
> > > > envelope/" xmlns:ns1="urn::robTest">
> > > >
> > > >
> > > > MYLOGINID
> > > > MYPASSWORD
> > > >
> > > >
> > > >
> > > > false
> > > >
> > > >
> > > > EOXML;
> >
> > > > function AuthenticationInfo($authinfo)
> > > > {
> > > > if ($authinfo->username != "MYLOGINID") {
> > > > return new SoapFault("F998", "Invalid USername");
> > > > } else if ($authinfo->password != "MYPASSWORD") {
> > > > return new SoapFault("F999", "Invalid Password");
> > > > }
> > > > /* Return value here would be used to add header to response */
> > > > }
> >
> > > > function GetTestList($getAll) {
> > > >return $getAll;
> > > > }
> >
> > > > $server = new SoapServer('http://www.cdatazone.org/files/rob.WSDL'<
> http://www.cdatazone.org/files/rob.WSDL%27>
> > > > );
> > > > $server->addFunction("GetTestList");
> > > > $server->addFunction("AuthenticationInfo");
> > > > $server->handle($xmlinput);
> > > > ?>
> >
> > > > Rob
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google G
[phpsoa] Re: SOAP Headers
Hi Kieran,
Sorry for not replying sooner. That's great news that you have
approval to work on this.
I'm a little concerned about having a soap header method on the
component because this will appear on any generated service interface
(e.g. .wsdl, .smd, etc), but should not be expliclity called by
clients. I guess we could exclude this in some way, but if there's a
way to separate it out, it might be better. I'll have a think about
this tomorrow and be sure to respond (even if I don't have any better
ideas).
FYI: the SCA_SDO project has an associated Contributors License
Agreement (CLA) (similar to that of Apache and the Zend Framework).
If you are willing to contribute the header support, it would need to
be done under this CLA. The CLA text file is in the PECL repository
and packaged in each release. I've noticed the CLA still refers to
the old project name (SDO) and will check whether or not this needs to
be fixed. If you have any questions about the CLA, please let me
know.
Regards, Graham.
On 5 Mar, 22:09, "Kieran James" <[EMAIL PROTECTED]> wrote:
> If there are no objections, I'll start work on it.
>
> Regards,
>
> Kieran
>
> On 3/4/07, 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.
>
> > Everyone,
>
> > My manager has approved me to work on SCA - specifically the
> > implementation of header support.
>
> > I suggest we work on the semantics of how this should work.
>
> > I think we should have an annotation above the class that defines which
> > function is going to process the header from the client, and annotations
> > above that function which defines the datatypes and such, for example:
>
> > /**
> > * @service
> > * @binding.ws
> > * @header authinfo
> > */
> > class service {
>
> > /**
> > * @param username $usernamehttp://accounts/Account
> > * @return statushttp://accounts/Account
> > */
> > function authinfo($username) {
>
> > }
>
> > }
>
> > If you have any thoughts, please let me know as I'd like to start work on
> > this as soon as possible.
>
> > Regards,
>
> > Kieran
>
> > On 3/2/07, Rob <[EMAIL PROTECTED]> wrote:
>
> > > On 1 Mar, 21:31, "Kieran James" <[EMAIL PROTECTED]> wrote:
> > > > I've only had a small amount of time to review the PHP SOAP extension.
> > > To
> > > > summarize from my brief exposure to it, I think that SoapHeader
> > > consumption
> > > > on the server side wouldn't be difficult to implement. I am still
> > > > investigating this, though time is scarce for me.
>
> > > > If I've not been clear enough on anything, please let me know.
>
> > > I am not sure if I'm missing something or not, but a SoapServer does
> > > process the headers as long as they are defined in the WSDL.
> > > It also will fault if header set to mustUnderstand and the function
> > > not implemented or not defined in WSDL.
> > > The only times the raw XML needs to be processed to access the headers
> > > is in the case of it not defined.
>
> > > > > $xmlinput = << > > http://schemas.xmlsoap.org/soap/
> > > envelope/" xmlns:ns1="urn::robTest">
> > >
> > >
> > > MYLOGINID
> > > MYPASSWORD
> > >
> > >
> > >
> > > false
> > >
> > >
> > > EOXML;
>
> > > function AuthenticationInfo($authinfo)
> > > {
> > > if ($authinfo->username != "MYLOGINID") {
> > > return new SoapFault("F998", "Invalid USername");
> > > } else if ($authinfo->password != "MYPASSWORD") {
> > > return new SoapFault("F999", "Invalid Password");
> > > }
> > > /* Return value here would be used to add header to response */
> > > }
>
> > > function GetTestList($getAll) {
> > >return $getAll;
> > > }
>
> > > $server = new
> > > SoapServer('http://www.cdatazone.org/files/rob.WSDL'
> > > );
> > > $server->addFunction("GetTestList");
> > > $server->addFunction("AuthenticationInfo");
> > > $server->handle($xmlinput);
> > > ?>
>
> > > 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
-~--~~~~--~~--~--~---
[phpsoa] Re: SOAP Headers
If there are no objections, I'll start work on it.
Regards,
Kieran
On 3/4/07, 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.
>
>
> Everyone,
>
> My manager has approved me to work on SCA - specifically the
> implementation of header support.
>
> I suggest we work on the semantics of how this should work.
>
> I think we should have an annotation above the class that defines which
> function is going to process the header from the client, and annotations
> above that function which defines the datatypes and such, for example:
>
> /**
> * @service
> * @binding.ws
> * @header authinfo
> */
> class service {
>
> /**
> * @param username $username http://accounts/Account
> * @return status http://accounts/Account
> */
> function authinfo($username) {
>
> }
>
> }
>
> If you have any thoughts, please let me know as I'd like to start work on
> this as soon as possible.
>
> Regards,
>
> Kieran
>
> On 3/2/07, Rob <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 1 Mar, 21:31, "Kieran James" <[EMAIL PROTECTED]> wrote:
> > > I've only had a small amount of time to review the PHP SOAP extension.
> > To
> > > summarize from my brief exposure to it, I think that SoapHeader
> > consumption
> > > on the server side wouldn't be difficult to implement. I am still
> > > investigating this, though time is scarce for me.
> > >
> > > If I've not been clear enough on anything, please let me know.
> >
> > I am not sure if I'm missing something or not, but a SoapServer does
> > process the headers as long as they are defined in the WSDL.
> > It also will fault if header set to mustUnderstand and the function
> > not implemented or not defined in WSDL.
> > The only times the raw XML needs to be processed to access the headers
> > is in the case of it not defined.
> >
> > > $xmlinput = << > http://schemas.xmlsoap.org/soap/
> > envelope/" xmlns:ns1="urn::robTest">
> >
> >
> > MYLOGINID
> > MYPASSWORD
> >
> >
> >
> > false
> >
> >
> > EOXML;
> >
> > function AuthenticationInfo($authinfo)
> > {
> > if ($authinfo->username != "MYLOGINID") {
> > return new SoapFault("F998", "Invalid USername");
> > } else if ($authinfo->password != "MYPASSWORD") {
> > return new SoapFault("F999", "Invalid Password");
> > }
> > /* Return value here would be used to add header to response */
> > }
> >
> > function GetTestList($getAll) {
> >return $getAll;
> > }
> >
> > $server = new SoapServer('
> > http://www.cdatazone.org/files/rob.WSDL'
> > );
> > $server->addFunction("GetTestList");
> > $server->addFunction("AuthenticationInfo");
> > $server->handle($xmlinput);
> > ?>
> >
> > 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
-~--~~~~--~~--~--~---
[phpsoa] Re: SOAP Headers
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.
Everyone,
My manager has approved me to work on SCA - specifically the implementation
of header support.
I suggest we work on the semantics of how this should work.
I think we should have an annotation above the class that defines which
function is going to process the header from the client, and annotations
above that function which defines the datatypes and such, for example:
/**
* @service
* @binding.ws
* @header authinfo
*/
class service {
/**
* @param username $username http://accounts/Account
* @return status http://accounts/Account
*/
function authinfo($username) {
}
}
If you have any thoughts, please let me know as I'd like to start work on
this as soon as possible.
Regards,
Kieran
On 3/2/07, Rob <[EMAIL PROTECTED]> wrote:
>
>
> On 1 Mar, 21:31, "Kieran James" <[EMAIL PROTECTED]> wrote:
> > I've only had a small amount of time to review the PHP SOAP extension.
> To
> > summarize from my brief exposure to it, I think that SoapHeader
> consumption
> > on the server side wouldn't be difficult to implement. I am still
> > investigating this, though time is scarce for me.
> >
> > If I've not been clear enough on anything, please let me know.
>
> I am not sure if I'm missing something or not, but a SoapServer does
> process the headers as long as they are defined in the WSDL.
> It also will fault if header set to mustUnderstand and the function
> not implemented or not defined in WSDL.
> The only times the raw XML needs to be processed to access the headers
> is in the case of it not defined.
>
> $xmlinput = << http://schemas.xmlsoap.org/soap/
> envelope/" xmlns:ns1="urn::robTest">
>
>
> MYLOGINID
> MYPASSWORD
>
>
>
> false
>
>
> EOXML;
>
> function AuthenticationInfo($authinfo)
> {
> if ($authinfo->username != "MYLOGINID") {
> return new SoapFault("F998", "Invalid USername");
> } else if ($authinfo->password != "MYPASSWORD") {
> return new SoapFault("F999", "Invalid Password");
> }
> /* Return value here would be used to add header to response */
> }
>
> function GetTestList($getAll) {
>return $getAll;
> }
>
> $server = new SoapServer('http://www.cdatazone.org/files/rob.WSDL');
> $server->addFunction("GetTestList");
> $server->addFunction("AuthenticationInfo");
> $server->handle($xmlinput);
> ?>
>
> 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
-~--~~~~--~~--~--~---
[phpsoa] Re: SOAP Headers
On 1 Mar, 21:31, "Kieran James" <[EMAIL PROTECTED]> wrote:
> I've only had a small amount of time to review the PHP SOAP extension. To
> summarize from my brief exposure to it, I think that SoapHeader consumption
> on the server side wouldn't be difficult to implement. I am still
> investigating this, though time is scarce for me.
>
> If I've not been clear enough on anything, please let me know.
I am not sure if I'm missing something or not, but a SoapServer does
process the headers as long as they are defined in the WSDL.
It also will fault if header set to mustUnderstand and the function
not implemented or not defined in WSDL.
The only times the raw XML needs to be processed to access the headers
is in the case of it not defined.
http://schemas.xmlsoap.org/soap/
envelope/" xmlns:ns1="urn::robTest">
MYLOGINID
MYPASSWORD
false
EOXML;
function AuthenticationInfo($authinfo)
{
if ($authinfo->username != "MYLOGINID") {
return new SoapFault("F998", "Invalid USername");
} else if ($authinfo->password != "MYPASSWORD") {
return new SoapFault("F999", "Invalid Password");
}
/* Return value here would be used to add header to response */
}
function GetTestList($getAll) {
return $getAll;
}
$server = new SoapServer('http://www.cdatazone.org/files/rob.WSDL');
$server->addFunction("GetTestList");
$server->addFunction("AuthenticationInfo");
$server->handle($xmlinput);
?>
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
-~--~~~~--~~--~--~---
[phpsoa] Re: SOAP Headers
Hi Graham,
I didn't think about what I was saying enough when I suggested Business and
Application logic should be able to see the SoapHeader.
I suggest that an ideal solution would be to bind SoapHeader to a header()
function optionally to each class.
Upon a SOAP client request for a function, the first step for SCA would be
to call the header() function and if the header function returns true then
the function that was called would then be invoked, otherwise a SoapFault
should be returned.
A crass example follows:
http://productsc/Product _data/XSD/Products.xsd
*/
class provisioning
{
/**
* @reference
* @binding.wsdl http://barra:8080/productsc.php?wsdl
*/
public $products;
/**
* @param fnn $fnn http://productsc/Product
* @return fnn http://productsc/Product
*/
function getExistingInfo($fnn)
{
$this->products->getByFNN("033959595");
return $fnn;
}
/**
* @param username $username http://products/Product
*/
function header($username)
{
if ($username=="fred")
{
return true;
} else {
return false;
}
}
}
?>
I've only had a small amount of time to review the PHP SOAP extension. To
summarize from my brief exposure to it, I think that SoapHeader consumption
on the server side wouldn't be difficult to implement. I am still
investigating this, though time is scarce for me.
If I've not been clear enough on anything, please let me know.
Regards,
Kieran.
On 3/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> Hi Kieran,
>
> I wrote a response a couple of days ago, but for some reason I can't
> see it here, so here goes again...
>
> On 27 Feb, 00:45, "[EMAIL PROTECTED]"
> <[EMAIL PROTECTED]> wrote:
> > Thanks for your replies,
> >
> > I'd like the WSDL generator to define the SOAP headers. Also the
> > business/application logic should be able to access any headers sent
> > from a SOAP client as SDO objects. I think the best place for the
> > definition of the headers would be in the annotations above each
> > class.
> >
>
> I like the idea of adding support to generate Soap headers in the
> WSDL. I agree that a class level annotation makes sense as the place
> to add the headers.
>
> I think of Soap headers as things which cut across services and
> ideally should not be surfaced in the business/applications logic
> (e.g. security). If the business logic needs the info, then I'd
> typically consider moving into the body.
>
> That said, there are sometimes reasons outside ones control which
> might lead to the requirement to access headers from application
> logic, so I wouldn't want us to proclude it, perhaps just not
> recommend it ;-)
>
>
> > The bug request mentioned seems to not have any real solution except
> > for the fact that there's no current way to do what I want using the
> > SoapServer from PHP.
> >
>
> The lack of real solution was partly why I mentioned it. Sorry I
> didn't make that clear.
>
> > Consequently, I've posted a feature request (http://bugs.php.net/
> > bug.php?id=40652) for writing SoapHeaders with SoapServer, although
> > after rereading my request, I may not have been clear enough. If you
> > were to post comments of support and/or clarification to the request
> > it would be greatly appreciated, and might give it some more swing.
> >
>
> I've added a comment to try to make sure whatever gets implemented can
> be used in SCA in an effective way.
>
> > Regards,
> >
> > Kieran
> >
> > On 26 Feb, 16:40, "[EMAIL PROTECTED]"
> >
> > <[EMAIL PROTECTED]> wrote:
> > > Hi,
> >
> > > I added the __setSoapHeader() to allow me to write a custom Binding
> > > for eBay. I needed to be able to flow an eBay CustomSecurityHeader in
> > > the SoapHeader. An extract of its use is as follows (I've modified
> > > the code a little to show how you would use it directly on the proxy
> > > rather than in a custom binding for clarity, but to preserve the
> > > protocol/business logic separation, this is best done in a binding):
> >
> > > $requester_credentials =
> > >
> $proxy->createDataObject('urn:ebay:apis:eBLBaseComponents',
> >
> > > 'CustomSecurityHeaderType');
> > > $requester_credentials->eBayAuthToken =
> $this->config['authtoken'];
> >
> > > $credentials =
> $requester_credentials->createDataObject('Credentials');
> >
> > > $credentials->AppId= $this->config['appid'];
> > > $credentials->DevId= $this->config['devid'];
> > > $credentials->AuthCert = $this->config['authcert'];
> > > $proxy->__setSoapHeader($requester_credentials,
> > >'urn:ebay:apis:eBLBaseComponents',
> > >'RequesterCredentials');
> > > $response = $proxy->GetSearchResults($request);
> >
> > > I think it would be good to
[phpsoa] Re: SOAP Headers
Hi Kieran,
Do you have any thoughts on how you'd like to see this enabled in the
SoapServer and then surfaced at the SCA level? It would be good to
mock up a scenario at both levels. I could take a stab at inventing a
scenario, but if you have something in mind, that would probably be a
better place to start.
Regards,
Graham.
On 1 Mar, 17:42, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Hi Kieran,
>
> I wrote a response a couple of days ago, but for some reason I can't
> see it here, so here goes again...
>
> On 27 Feb, 00:45, "[EMAIL PROTECTED]"
>
> <[EMAIL PROTECTED]> wrote:
> > Thanks for your replies,
>
> > I'd like the WSDL generator to define the SOAP headers. Also the
> > business/application logic should be able to access any headers sent
> > from a SOAP client as SDO objects. I think the best place for the
> > definition of the headers would be in the annotations above each
> > class.
>
> I like the idea of adding support to generate Soap headers in the
> WSDL. I agree that a class level annotation makes sense as the place
> to add the headers.
>
> I think of Soap headers as things which cut across services and
> ideally should not be surfaced in the business/applications logic
> (e.g. security). If the business logic needs the info, then I'd
> typically consider moving into the body.
>
> That said, there are sometimes reasons outside ones control which
> might lead to the requirement to access headers from application
> logic, so I wouldn't want us to proclude it, perhaps just not
> recommend it ;-)
>
> > The bug request mentioned seems to not have any real solution except
> > for the fact that there's no current way to do what I want using the
> > SoapServer from PHP.
>
> The lack of real solution was partly why I mentioned it. Sorry I
> didn't make that clear.
>
> > Consequently, I've posted a feature request (http://bugs.php.net/
> > bug.php?id=40652) for writing SoapHeaders with SoapServer, although
> > after rereading my request, I may not have been clear enough. If you
> > were to post comments of support and/or clarification to the request
> > it would be greatly appreciated, and might give it some more swing.
>
> I've added a comment to try to make sure whatever gets implemented can
> be used in SCA in an effective way.
>
> > Regards,
>
> > Kieran
>
> > On 26 Feb, 16:40, "[EMAIL PROTECTED]"
>
> > <[EMAIL PROTECTED]> wrote:
> > > Hi,
>
> > > I added the __setSoapHeader() to allow me to write a custom Binding
> > > for eBay. I needed to be able to flow an eBay CustomSecurityHeader in
> > > the SoapHeader. An extract of its use is as follows (I've modified
> > > the code a little to show how you would use it directly on the proxy
> > > rather than in a custom binding for clarity, but to preserve the
> > > protocol/business logic separation, this is best done in a binding):
>
> > > $requester_credentials =
> > >
> > > $proxy->createDataObject('urn:ebay:apis:eBLBaseComponents',
>
> > > 'CustomSecurityHeaderType');
> > > $requester_credentials->eBayAuthToken =
> > > $this->config['authtoken'];
>
> > > $credentials =
> > > $requester_credentials->createDataObject('Credentials');
>
> > > $credentials->AppId= $this->config['appid'];
> > > $credentials->DevId= $this->config['devid'];
> > > $credentials->AuthCert = $this->config['authcert'];
> > > $proxy->__setSoapHeader($requester_credentials,
> > >'urn:ebay:apis:eBLBaseComponents',
> > >'RequesterCredentials');
> > > $response = $proxy->GetSearchResults($request);
>
> > > I think it would be good to provide the equivalent on the server
> > > side. This would probably be best used by custom binding
> > > implementations to keep header handling separate from business logic
> > > (I'm not sure how this could be cleanly done any other way since an
> > > SCA component does not know about the binding implementation, so can't
> > > easily explicitly request the header).
>
> > > Ideally the SoapServer would provide a hook for this to be
> > > implemented, but unfortunately this is not the case
> > > (seehttp://bugs.php.net/bug.php?id=38309). It may be possible to extend
> > > the SCA_Bindings_ws_ServiceRequestHandler to parse out the header into
> > > an SDO, but this will impact performance (the SoapServer has already
> > > parsed the request once).
>
> > > We may be able to request that the SoapServer provide the hook (or
> > > offer to contribute it), if that's what we decide is the best way
> > > forward.
>
> > > On 26 Feb, 11:51, [EMAIL PROTECTED] wrote:
>
> > > > On 26 Feb, 00:54, "[EMAIL PROTECTED]"
>
> > > > <[EMAIL PROTECTED]> wrote:
> > > > > Hi,
>
> > > > > I'm working with a medium sized telco in Australia to reimplement
> > > > > their CRM. First thing we're doing is to turn all their core se
[phpsoa] Re: SOAP Headers
Hi Kieran,
I wrote a response a couple of days ago, but for some reason I can't
see it here, so here goes again...
On 27 Feb, 00:45, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Thanks for your replies,
>
> I'd like the WSDL generator to define the SOAP headers. Also the
> business/application logic should be able to access any headers sent
> from a SOAP client as SDO objects. I think the best place for the
> definition of the headers would be in the annotations above each
> class.
>
I like the idea of adding support to generate Soap headers in the
WSDL. I agree that a class level annotation makes sense as the place
to add the headers.
I think of Soap headers as things which cut across services and
ideally should not be surfaced in the business/applications logic
(e.g. security). If the business logic needs the info, then I'd
typically consider moving into the body.
That said, there are sometimes reasons outside ones control which
might lead to the requirement to access headers from application
logic, so I wouldn't want us to proclude it, perhaps just not
recommend it ;-)
> The bug request mentioned seems to not have any real solution except
> for the fact that there's no current way to do what I want using the
> SoapServer from PHP.
>
The lack of real solution was partly why I mentioned it. Sorry I
didn't make that clear.
> Consequently, I've posted a feature request (http://bugs.php.net/
> bug.php?id=40652) for writing SoapHeaders with SoapServer, although
> after rereading my request, I may not have been clear enough. If you
> were to post comments of support and/or clarification to the request
> it would be greatly appreciated, and might give it some more swing.
>
I've added a comment to try to make sure whatever gets implemented can
be used in SCA in an effective way.
> Regards,
>
> Kieran
>
> On 26 Feb, 16:40, "[EMAIL PROTECTED]"
>
> <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> > I added the __setSoapHeader() to allow me to write a custom Binding
> > for eBay. I needed to be able to flow an eBay CustomSecurityHeader in
> > the SoapHeader. An extract of its use is as follows (I've modified
> > the code a little to show how you would use it directly on the proxy
> > rather than in a custom binding for clarity, but to preserve the
> > protocol/business logic separation, this is best done in a binding):
>
> > $requester_credentials =
> > $proxy->createDataObject('urn:ebay:apis:eBLBaseComponents',
>
> > 'CustomSecurityHeaderType');
> > $requester_credentials->eBayAuthToken =
> > $this->config['authtoken'];
>
> > $credentials =
> > $requester_credentials->createDataObject('Credentials');
>
> > $credentials->AppId= $this->config['appid'];
> > $credentials->DevId= $this->config['devid'];
> > $credentials->AuthCert = $this->config['authcert'];
> > $proxy->__setSoapHeader($requester_credentials,
> >'urn:ebay:apis:eBLBaseComponents',
> >'RequesterCredentials');
> > $response = $proxy->GetSearchResults($request);
>
> > I think it would be good to provide the equivalent on the server
> > side. This would probably be best used by custom binding
> > implementations to keep header handling separate from business logic
> > (I'm not sure how this could be cleanly done any other way since an
> > SCA component does not know about the binding implementation, so can't
> > easily explicitly request the header).
>
> > Ideally the SoapServer would provide a hook for this to be
> > implemented, but unfortunately this is not the case
> > (seehttp://bugs.php.net/bug.php?id=38309). It may be possible to extend
> > the SCA_Bindings_ws_ServiceRequestHandler to parse out the header into
> > an SDO, but this will impact performance (the SoapServer has already
> > parsed the request once).
>
> > We may be able to request that the SoapServer provide the hook (or
> > offer to contribute it), if that's what we decide is the best way
> > forward.
>
> > On 26 Feb, 11:51, [EMAIL PROTECTED] wrote:
>
> > > On 26 Feb, 00:54, "[EMAIL PROTECTED]"
>
> > > <[EMAIL PROTECTED]> wrote:
> > > > Hi,
>
> > > > I'm working with a medium sized telco in Australia to reimplement
> > > > their CRM. First thing we're doing is to turn all their core services
> > > > into SOAP exposed services.
>
> > > > SOAP headers would make our life a lot easier. I've read the
> > > > documentation and had a quick look at the source code - but it seems
> > > > as though there's no way to do this.
>
> > > > Is there technical limitations as to why this isn't implemented? We
> > > > have a few developers here, and if it's not too difficult to implement
> > > > we may be ale to allocate resources to implementing it.
>
> > > > Great work, by the way.
>
> > > > Regards,
>
> > > > Kieran
>
> > > Hi Kieran and thanks:-)
>
> > > Do y
[phpsoa] Re: SOAP Headers
Thanks for your replies,
I'd like the WSDL generator to define the SOAP headers. Also the
business/application logic should be able to access any headers sent
from a SOAP client as SDO objects. I think the best place for the
definition of the headers would be in the annotations above each
class.
The bug request mentioned seems to not have any real solution except
for the fact that there's no current way to do what I want using the
SoapServer from PHP.
Consequently, I've posted a feature request (http://bugs.php.net/
bug.php?id=40652) for writing SoapHeaders with SoapServer, although
after rereading my request, I may not have been clear enough. If you
were to post comments of support and/or clarification to the request
it would be greatly appreciated, and might give it some more swing.
Regards,
Kieran
On 26 Feb, 16:40, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I added the __setSoapHeader() to allow me to write a custom Binding
> for eBay. I needed to be able to flow an eBay CustomSecurityHeader in
> the SoapHeader. An extract of its use is as follows (I've modified
> the code a little to show how you would use it directly on the proxy
> rather than in a custom binding for clarity, but to preserve the
> protocol/business logic separation, this is best done in a binding):
>
> $requester_credentials =
> $proxy->createDataObject('urn:ebay:apis:eBLBaseComponents',
>
> 'CustomSecurityHeaderType');
> $requester_credentials->eBayAuthToken =
> $this->config['authtoken'];
>
> $credentials =
> $requester_credentials->createDataObject('Credentials');
>
> $credentials->AppId= $this->config['appid'];
> $credentials->DevId= $this->config['devid'];
> $credentials->AuthCert = $this->config['authcert'];
> $proxy->__setSoapHeader($requester_credentials,
>'urn:ebay:apis:eBLBaseComponents',
>'RequesterCredentials');
> $response = $proxy->GetSearchResults($request);
>
> I think it would be good to provide the equivalent on the server
> side. This would probably be best used by custom binding
> implementations to keep header handling separate from business logic
> (I'm not sure how this could be cleanly done any other way since an
> SCA component does not know about the binding implementation, so can't
> easily explicitly request the header).
>
> Ideally the SoapServer would provide a hook for this to be
> implemented, but unfortunately this is not the case
> (seehttp://bugs.php.net/bug.php?id=38309). It may be possible to extend
> the SCA_Bindings_ws_ServiceRequestHandler to parse out the header into
> an SDO, but this will impact performance (the SoapServer has already
> parsed the request once).
>
> We may be able to request that the SoapServer provide the hook (or
> offer to contribute it), if that's what we decide is the best way
> forward.
>
> On 26 Feb, 11:51, [EMAIL PROTECTED] wrote:
>
> > On 26 Feb, 00:54, "[EMAIL PROTECTED]"
>
> > <[EMAIL PROTECTED]> wrote:
> > > Hi,
>
> > > I'm working with a medium sized telco in Australia to reimplement
> > > their CRM. First thing we're doing is to turn all their core services
> > > into SOAP exposed services.
>
> > > SOAP headers would make our life a lot easier. I've read the
> > > documentation and had a quick look at the source code - but it seems
> > > as though there's no way to do this.
>
> > > Is there technical limitations as to why this isn't implemented? We
> > > have a few developers here, and if it's not too difficult to implement
> > > we may be ale to allocate resources to implementing it.
>
> > > Great work, by the way.
>
> > > Regards,
>
> > > Kieran
>
> > Hi Kieran and thanks:-)
>
> > Do you mean you want to be able to set the SOAP hearders that are sent
> > with a SOAP request? Looking at the AVOCET branch in CVS it seems
> > Graham Charters has had this problem as a method was added to allow
> > SOAP headers to be set. If you look in the branch at file SCA/Bindings/
> > ws/Proxy.php there is a new method.
>
> > public function __setSoapHeader($header_sdo, $ns, $name) {
>
> > I don't see any examples of how to use it though so maybe Graham will
> > comment with some detail on the ins and outs of the change.
>
> > If you want to read the SOAP headers in a service then I'm not sure
> > how you go about it at present. There is no technical reason why we
> > shouldn't allow access to the headers but we would have to add an API
> > to retireve the information for a call.
>
> > Thanks for the offer of help it's very welcome. Lets discuss your
> > exact requirements here then we can work out how we implement it.
>
> > Regards
>
> > Simon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"phpsoa" group.
To post to this group, send emai
[phpsoa] Re: SOAP Headers
Hi,
I added the __setSoapHeader() to allow me to write a custom Binding
for eBay. I needed to be able to flow an eBay CustomSecurityHeader in
the SoapHeader. An extract of its use is as follows (I've modified
the code a little to show how you would use it directly on the proxy
rather than in a custom binding for clarity, but to preserve the
protocol/business logic separation, this is best done in a binding):
$requester_credentials =
$proxy-
>createDataObject('urn:ebay:apis:eBLBaseComponents',
'CustomSecurityHeaderType');
$requester_credentials->eBayAuthToken = $this-
>config['authtoken'];
$credentials = $requester_credentials-
>createDataObject('Credentials');
$credentials->AppId= $this->config['appid'];
$credentials->DevId= $this->config['devid'];
$credentials->AuthCert = $this->config['authcert'];
$proxy->__setSoapHeader($requester_credentials,
'urn:ebay:apis:eBLBaseComponents',
'RequesterCredentials');
$response = $proxy->GetSearchResults($request);
I think it would be good to provide the equivalent on the server
side. This would probably be best used by custom binding
implementations to keep header handling separate from business logic
(I'm not sure how this could be cleanly done any other way since an
SCA component does not know about the binding implementation, so can't
easily explicitly request the header).
Ideally the SoapServer would provide a hook for this to be
implemented, but unfortunately this is not the case (see
http://bugs.php.net/bug.php?id=38309). It may be possible to extend
the SCA_Bindings_ws_ServiceRequestHandler to parse out the header into
an SDO, but this will impact performance (the SoapServer has already
parsed the request once).
We may be able to request that the SoapServer provide the hook (or
offer to contribute it), if that's what we decide is the best way
forward.
On 26 Feb, 11:51, [EMAIL PROTECTED] wrote:
> On 26 Feb, 00:54, "[EMAIL PROTECTED]"
>
> <[EMAIL PROTECTED]> wrote:
> > Hi,
>
> > I'm working with a medium sized telco in Australia to reimplement
> > their CRM. First thing we're doing is to turn all their core services
> > into SOAP exposed services.
>
> > SOAP headers would make our life a lot easier. I've read the
> > documentation and had a quick look at the source code - but it seems
> > as though there's no way to do this.
>
> > Is there technical limitations as to why this isn't implemented? We
> > have a few developers here, and if it's not too difficult to implement
> > we may be ale to allocate resources to implementing it.
>
> > Great work, by the way.
>
> > Regards,
>
> > Kieran
>
> Hi Kieran and thanks:-)
>
> Do you mean you want to be able to set the SOAP hearders that are sent
> with a SOAP request? Looking at the AVOCET branch in CVS it seems
> Graham Charters has had this problem as a method was added to allow
> SOAP headers to be set. If you look in the branch at file SCA/Bindings/
> ws/Proxy.php there is a new method.
>
> public function __setSoapHeader($header_sdo, $ns, $name) {
>
> I don't see any examples of how to use it though so maybe Graham will
> comment with some detail on the ins and outs of the change.
>
> If you want to read the SOAP headers in a service then I'm not sure
> how you go about it at present. There is no technical reason why we
> shouldn't allow access to the headers but we would have to add an API
> to retireve the information for a call.
>
> Thanks for the offer of help it's very welcome. Lets discuss your
> exact requirements here then we can work out how we implement it.
>
> Regards
>
> Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[phpsoa] Re: SOAP Headers
On 26 Feb, 00:54, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm working with a medium sized telco in Australia to reimplement
> their CRM. First thing we're doing is to turn all their core services
> into SOAP exposed services.
>
> SOAP headers would make our life a lot easier. I've read the
> documentation and had a quick look at the source code - but it seems
> as though there's no way to do this.
>
> Is there technical limitations as to why this isn't implemented? We
> have a few developers here, and if it's not too difficult to implement
> we may be ale to allocate resources to implementing it.
>
> Great work, by the way.
>
> Regards,
>
> Kieran
Hi Kieran and thanks:-)
Do you mean you want to be able to set the SOAP hearders that are sent
with a SOAP request? Looking at the AVOCET branch in CVS it seems
Graham Charters has had this problem as a method was added to allow
SOAP headers to be set. If you look in the branch at file SCA/Bindings/
ws/Proxy.php there is a new method.
public function __setSoapHeader($header_sdo, $ns, $name) {
I don't see any examples of how to use it though so maybe Graham will
comment with some detail on the ins and outs of the change.
If you want to read the SOAP headers in a service then I'm not sure
how you go about it at present. There is no technical reason why we
shouldn't allow access to the headers but we would have to add an API
to retireve the information for a call.
Thanks for the offer of help it's very welcome. Lets discuss your
exact requirements here then we can work out how we implement it.
Regards
Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
