|New Proposal Template|
This page has been created from a template that uses "zones." To proceed:
An automated SOAP/XML-RPC/REST server that will Initial idea is based on my original efforts on
Proposed Component Name
1.0 - 1 August 2006: Intial Proposal. (wiki revision: 2)
expose any code using any of the above protocols.
Zend_Service_Server will also generate
WSDL generation for Cerebral Cortex. It has since
come to my attention, there is also (again, SOAP
specific) PEAR's Net_Service.
An automated SOAP/XML-RPC/REST server that will
Initial idea is based on my original efforts on
Must allow the user to expose any class with no
special requirements placed on the author. The
only exception to this is that all methods must
return values, they cannot simply output them.
All servers must provide a SoapServer-like interface
allowing for instantiation outside of this automated
process and registering of both single class and
multiple functions. They should also provide a way to
generate documentation specific to the implementation.
- Zend_XmlRpc_Server (not yet created)
Zend_Service_Server will require that a file
containing a class be given as the constructor
argument. This is required because the tokenizer
extension is used for PHP 5.0.x compatibility
(though, I forget the /exact/ problem with
ext/reflection that prompted this decision).
The operation from here depends on the GET arguments.
The operations allowed are as follows:
?wsdl = WSDL Generation
?soap = SOAP Server (using ext/soap's SoapServer)
?rest = REST Server (using Zend_Service_Server_Rest)
?rpc = XML-RPC Server (using Zend_XmlRpc_Server)
Passing no argument will output user-readable documentation,
detailing the methods exposed. If you supply one of the
above and the 'docs' argument, it will output
implementation specific documentation, and possibly
allow for submission of requests using a form (a la
- Zend_Service_Server - Class that handles user request and
forwards request to implementation specific server
- Zend_Service_Server_Interface - Interface that all (except
ext/soap) must implement to be accepted as backends.
- Zend_Service_Server_Rest - REST server; this will either create
a nice markup based on reflection, or will allow
the user to return SimpleXML, DomDocument or DomNode objects.
- Zend_Service_Server_Soap_WsdlCreator - Generates WSDL files for
- Zend_Service_Server_Wsdl - WSDL Toolkit for creating WSDL
files (not automated)
- Zend_Service_Server_Wsdl_Parser - WSDL Parser
- Zend_Service_Server_Wsdl_Parser_Result - WSDL Parser Result
- Zend_Service_Server_Wsdl_CodeGenerator - WSDL -> PHP Skeleton
In addition to these, there will be the documentation creators:
Furthermore, depending on the implementation of Zend_XmlRpc_Server
there may be a requirement to wrap it with a Zend_Service_Server_XmlRpc
class to make it conform to the Zend_Service_Server_Interface API.
Finally, there will need to be a REST client class, whether this is
implemented within Zend_Service_Rest or as another entity is undecided.
The ultimate use-case for this is anybody wishing to provide
webservices to their users and not wanting to be tied to a specific
technology (i.e. SOAP). It also allows for additional backends to be
plugged in at will for custom formats.
Documentation classes are seen as specialized HTML responding servers.
REST client that works with Zend_Service_Server_Rest automatically.]]></ac:plain-text-body></ac:macro>