On 31 Aug, 08:42, Graham Charters <[EMAIL PROTECTED]> wrote:
> Pecl Request #11944 (http://pecl.php.net/bugs/bug.php?id=11944) is
> asking for finer-grained control over the methods which are surfaced
> on a service interface. We currently just use class visibility (i.e.
> all public methods) to control this.
>
> There's a small amount of discussion in the request, but I thought it
> would be good to raise it here to get greater visibility and gather
> more options/opinions.
>
> Graham.
Following up on the comments made in the feature request...
It is true that in the Java SCA implementation the @Service
information is associated with interfaces so a class will implementat
one, or more, interfaces and this tells the runtime which methods of
the class should be treated as service methods.
This is not currently how the PHP SCA implementation works. All
annotations are placed on the class itself. This leads to a level of
simplicity in service construction but we pay for this in lack of
flexibility, for example, in excluding some methods from the service
interface. At least given the set of annotations we have at the
moment.
Having said this I'm not convinced that the use of unannotated (is
that a word?) methods as part of the service interface makes a lot of
sense give the way that the implementation works at the moment. If you
look at what is actually generated in the WSDL in the case of the
method "function foo($bar)" in the feature request it doesn't seem to
be that useful. I.e. it defines null input and output types. I assume
this is because there are no annotations for SCA to use for typing the
interface. Fine for PHP but not so great for a service interface.
So there are two issues here
1/ What should SCA do if it finds a method without annotations, i.e.
no type information
2/ How can methods be omitted from the service interface, i.e. we just
don't want to expose the method
As first suggested we could omit methods that don't have comments at
all.. However this is problematic for issue 2 as annotations may have
been included for producing the documentation that the annotations
were originally designed for. However I think we should consider
omitting methods without annotations due to issue 1 so this could be a
short term solution 2.
Following the conversation on for issue 2. Maybe, as an alternative to
@scaExcludeMethod we could defined some new annotation for the header
block that works as an alternative to defining an interface (we should
look whether interfaces could be made to work), e.g.
/**
* Scaffold implementation for a remote StockQuote Web service.
*
* @service
* @serviceinterface GetQuote getQuote
* @binding.soap
*
*/
If these don't appear then the default would be to operate as now
with all of the (annotated) methods being parsed. The intention here
being to replace/augment this with annotations on interfaces if/'when
they work.
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
-~----------~----~----~----~------~----~------~--~---
