New Proposal Template This page has been created from a template that uses "zones." To proceed:

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Service_Server Component Proposal

Table of Contents

1. Overview

An automated SOAP/XML-RPC/REST server that will
expose any code using any of the above protocols.
Zend_Service_Server will also generate
human-readable documentation.

2. References

Initial idea is based on my original efforts on
WSDL generation for Cerebral Cortex. It has since
come to my attention, there is also (again, SOAP
specific) PEAR's Net_Service.

• Crtx_SOAP_AutoDiscover
• PEAR::Service_Webservice

3. Component Requirements, Constraints, and Acceptance Criteria

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.

4. Dependencies on Other Framework Components

• Zend_Uri
• Zend_XmlRpc_Server (not yet created)
• Zend_Service_Exception

5. Theory of Operation

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
.NET)

6. Milestones / Tasks

7. Class Index

• 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
  classes automatically.

• 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
  container

• Zend_Service_Server_Wsdl_CodeGenerator - WSDL -> PHP Skeleton
  creator

In addition to these, there will be the documentation creators:

• Zend_Service_Server_Documentor

• Zend_Service_Server_Documentor_REST

• Zend_Service_Server_Documentor_XmlRpc

• Zend_Service_Server_Documentor_Soap

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.

8. Use Cases

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.

Front facing file

testClass.php

Example Exchanges

Request

Response

Request

Response

Request

Response

9. Class Skeletons

Documentation classes are seen as specialized HTML responding servers.

ToDo:

REST client that works with Zend_Service_Server_Rest automatically.